diff options
Diffstat (limited to 'results/classifier/105/KVM')
250 files changed, 39431 insertions, 0 deletions
diff --git a/results/classifier/105/KVM/04472277 b/results/classifier/105/KVM/04472277 new file mode 100644 index 00000000..e3118005 --- /dev/null +++ b/results/classifier/105/KVM/04472277 @@ -0,0 +1,584 @@ +KVM: 0.890 +device: 0.849 +network: 0.847 +graphic: 0.846 +other: 0.846 +instruction: 0.845 +assembly: 0.841 +boot: 0.831 +vnc: 0.828 +socket: 0.824 +mistranslation: 0.817 +semantic: 0.815 + +[BUG][KVM_SET_USER_MEMORY_REGION] KVM_SET_USER_MEMORY_REGION failed + +Hi all, +I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR. +Is there any one know this? +The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log +``` +2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-14 10:09:18.198+0000: shutting down, reason=crashed +``` +The xml file +``` +root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit instance-0000000e +or other application using the libvirt API. +--> +<domain type='kvm'> + <name>instance-0000000e</name> + <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid> + <metadata> +  <nova:instance xmlns:nova=" +http://openstack.org/xmlns/libvirt/nova/1.1 +"> +   <nova:package version="25.1.0"/> +   <nova:name>provider-instance</nova:name> +   <nova:creationTime>2023-03-14 10:09:13</nova:creationTime> +   <nova:flavor name="cirros-os-dpu-test-1"> +    <nova:memory>64</nova:memory> +    <nova:disk>1</nova:disk> +    <nova:swap>0</nova:swap> +    <nova:ephemeral>0</nova:ephemeral> +    <nova:vcpus>1</nova:vcpus> +   </nova:flavor> +   <nova:owner> +    <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user> +    <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project> +   </nova:owner> +   <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/> +   <nova:ports> +    <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340"> +     <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/> +    </nova:port> +   </nova:ports> +  </nova:instance> + </metadata> + <memory unit='KiB'>65536</memory> + <currentMemory unit='KiB'>65536</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> +  <system> +   <entry name='manufacturer'>OpenStack Foundation</entry> +   <entry name='product'>OpenStack Nova</entry> +   <entry name='version'>25.1.0</entry> +   <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='family'>Virtual Machine</entry> +  </system> + </sysinfo> + <os> +  <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type> +  <boot dev='hd'/> +  <smbios mode='sysinfo'/> + </os> + <features> +  <acpi/> +  <apic/> +  <vmcoreinfo state='on'/> + </features> + <cpu mode='host-model' check='partial'> +  <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <clock offset='utc'> +  <timer name='pit' tickpolicy='delay'/> +  <timer name='rtc' tickpolicy='catchup'/> +  <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> +  <emulator>/usr/bin/qemu-system-x86_64</emulator> +  <disk type='file' device='disk'> +   <driver name='qemu' type='qcow2' cache='none'/> +   <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/> +   <target dev='vda' bus='virtio'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +  </disk> +  <controller type='usb' index='0' model='piix3-uhci'> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> +  </controller> +  <controller type='pci' index='0' model='pci-root'/> +  <interface type='hostdev' managed='yes'> +   <mac address='fa:16:3e:aa:d9:23'/> +   <source> +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> +  </interface> +  <serial type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='isa-serial' port='0'> +    <model name='isa-serial'/> +   </target> +  </serial> +  <console type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='serial' port='0'/> +  </console> +  <input type='tablet' bus='usb'> +   <address type='usb' bus='0' port='1'/> +  </input> +  <input type='mouse' bus='ps2'/> +  <input type='keyboard' bus='ps2'/> +  <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> +   <listen type='address' address='0.0.0.0'/> +  </graphics> +  <audio id='1' type='none'/> +  <video> +   <model type='virtio' heads='1' primary='yes'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> +  </video> +  <hostdev mode='subsystem' type='pci' managed='yes'> +   <source> +    <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> +  </hostdev> +  <memballoon model='virtio'> +   <stats period='10'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +  </memballoon> +  <rng model='virtio'> +   <backend model='random'>/dev/urandom</backend> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> +  </rng> + </devices> +</domain> +``` +---- +Simon Jones + +This is happened in ubuntu22.04. +QEMU is install by apt like this: +apt install -y qemu qemu-kvm qemu-system +and QEMU version is 6.2.0 +---- +Simon Jones +Simon Jones < +batmanustc@gmail.com +> äº2023å¹´3æ21æ¥å¨äº 08:40åéï¼ +Hi all, +I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR. +Is there any one know this? +The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log +``` +2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-14 10:09:18.198+0000: shutting down, reason=crashed +``` +The xml file +``` +root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit instance-0000000e +or other application using the libvirt API. +--> +<domain type='kvm'> + <name>instance-0000000e</name> + <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid> + <metadata> +  <nova:instance xmlns:nova=" +http://openstack.org/xmlns/libvirt/nova/1.1 +"> +   <nova:package version="25.1.0"/> +   <nova:name>provider-instance</nova:name> +   <nova:creationTime>2023-03-14 10:09:13</nova:creationTime> +   <nova:flavor name="cirros-os-dpu-test-1"> +    <nova:memory>64</nova:memory> +    <nova:disk>1</nova:disk> +    <nova:swap>0</nova:swap> +    <nova:ephemeral>0</nova:ephemeral> +    <nova:vcpus>1</nova:vcpus> +   </nova:flavor> +   <nova:owner> +    <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user> +    <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project> +   </nova:owner> +   <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/> +   <nova:ports> +    <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340"> +     <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/> +    </nova:port> +   </nova:ports> +  </nova:instance> + </metadata> + <memory unit='KiB'>65536</memory> + <currentMemory unit='KiB'>65536</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> +  <system> +   <entry name='manufacturer'>OpenStack Foundation</entry> +   <entry name='product'>OpenStack Nova</entry> +   <entry name='version'>25.1.0</entry> +   <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='family'>Virtual Machine</entry> +  </system> + </sysinfo> + <os> +  <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type> +  <boot dev='hd'/> +  <smbios mode='sysinfo'/> + </os> + <features> +  <acpi/> +  <apic/> +  <vmcoreinfo state='on'/> + </features> + <cpu mode='host-model' check='partial'> +  <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <clock offset='utc'> +  <timer name='pit' tickpolicy='delay'/> +  <timer name='rtc' tickpolicy='catchup'/> +  <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> +  <emulator>/usr/bin/qemu-system-x86_64</emulator> +  <disk type='file' device='disk'> +   <driver name='qemu' type='qcow2' cache='none'/> +   <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/> +   <target dev='vda' bus='virtio'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +  </disk> +  <controller type='usb' index='0' model='piix3-uhci'> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> +  </controller> +  <controller type='pci' index='0' model='pci-root'/> +  <interface type='hostdev' managed='yes'> +   <mac address='fa:16:3e:aa:d9:23'/> +   <source> +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> +  </interface> +  <serial type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='isa-serial' port='0'> +    <model name='isa-serial'/> +   </target> +  </serial> +  <console type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='serial' port='0'/> +  </console> +  <input type='tablet' bus='usb'> +   <address type='usb' bus='0' port='1'/> +  </input> +  <input type='mouse' bus='ps2'/> +  <input type='keyboard' bus='ps2'/> +  <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> +   <listen type='address' address='0.0.0.0'/> +  </graphics> +  <audio id='1' type='none'/> +  <video> +   <model type='virtio' heads='1' primary='yes'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> +  </video> +  <hostdev mode='subsystem' type='pci' managed='yes'> +   <source> +    <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> +  </hostdev> +  <memballoon model='virtio'> +   <stats period='10'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +  </memballoon> +  <rng model='virtio'> +   <backend model='random'>/dev/urandom</backend> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> +  </rng> + </devices> +</domain> +``` +---- +Simon Jones + +This is full ERROR log +2023-03-23 08:00:52.362+0000: starting up libvirt version: 8.0.0, package: 1ubuntu7.4 (Christian Ehrhardt < +christian.ehrhardt@canonical.com +> Tue, 22 Nov 2022 15:59:28 +0100), qemu version: 6.2.0Debian 1:6.2+dfsg-2ubuntu6.6, kernel: 5.19.0-35-generic, hostname: c1c2 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ +HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=instance-0000000e,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-instance-0000000e/master-key.aes"}' \ +-machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off \ +-m 64 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":67108864}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,dies=1,cores=1,threads=1 \ +-uuid ff91d2dc-69a1-43ef-abde-c9e4e9a0305b \ +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.1.0,serial=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,uuid=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,family=Virtual Machine' \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/_base/8b58db82a488248e7c5e769599954adaa47a5314","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-add-fd set=1,fd=34 \ +-chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-device usb-tablet,id=input0,bus=usb.0,port=1 \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc +0.0.0.0:0 +,audiodev=audio1 \ +-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \ +-device vfio-pci,host=0000:01:00.5,id=hostdev0,bus=pci.0,addr=0x4 \ +-device vfio-pci,host=0000:01:00.6,id=hostdev1,bus=pci.0,addr=0x5 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 \ +-device vmcoreinfo \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charserial0) +2023-03-23T08:00:53.728550Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-23 08:00:54.201+0000: shutting down, reason=crashed +2023-03-23 08:54:43.468+0000: starting up libvirt version: 8.0.0, package: 1ubuntu7.4 (Christian Ehrhardt < +christian.ehrhardt@canonical.com +> Tue, 22 Nov 2022 15:59:28 +0100), qemu version: 6.2.0Debian 1:6.2+dfsg-2ubuntu6.6, kernel: 5.19.0-35-generic, hostname: c1c2 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ +HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=instance-0000000e,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-5-instance-0000000e/master-key.aes"}' \ +-machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off \ +-m 64 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":67108864}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,dies=1,cores=1,threads=1 \ +-uuid ff91d2dc-69a1-43ef-abde-c9e4e9a0305b \ +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.1.0,serial=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,uuid=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,family=Virtual Machine' \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/_base/8b58db82a488248e7c5e769599954adaa47a5314","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-add-fd set=1,fd=34 \ +-chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-device usb-tablet,id=input0,bus=usb.0,port=1 \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc +0.0.0.0:0 +,audiodev=audio1 \ +-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \ +-device vfio-pci,host=0000:01:00.5,id=hostdev0,bus=pci.0,addr=0x4 \ +-device vfio-pci,host=0000:01:00.6,id=hostdev1,bus=pci.0,addr=0x5 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 \ +-device vmcoreinfo \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charserial0) +2023-03-23T08:54:44.755039Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-23 08:54:45.230+0000: shutting down, reason=crashed +---- +Simon Jones +Simon Jones < +batmanustc@gmail.com +> äº2023å¹´3æ23æ¥å¨å 05:49åéï¼ +This is happened in ubuntu22.04. +QEMU is install by apt like this: +apt install -y qemu qemu-kvm qemu-system +and QEMU version is 6.2.0 +---- +Simon Jones +Simon Jones < +batmanustc@gmail.com +> äº2023å¹´3æ21æ¥å¨äº 08:40åéï¼ +Hi all, +I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR. +Is there any one know this? +The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log +``` +2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-14 10:09:18.198+0000: shutting down, reason=crashed +``` +The xml file +``` +root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit instance-0000000e +or other application using the libvirt API. +--> +<domain type='kvm'> + <name>instance-0000000e</name> + <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid> + <metadata> +  <nova:instance xmlns:nova=" +http://openstack.org/xmlns/libvirt/nova/1.1 +"> +   <nova:package version="25.1.0"/> +   <nova:name>provider-instance</nova:name> +   <nova:creationTime>2023-03-14 10:09:13</nova:creationTime> +   <nova:flavor name="cirros-os-dpu-test-1"> +    <nova:memory>64</nova:memory> +    <nova:disk>1</nova:disk> +    <nova:swap>0</nova:swap> +    <nova:ephemeral>0</nova:ephemeral> +    <nova:vcpus>1</nova:vcpus> +   </nova:flavor> +   <nova:owner> +    <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user> +    <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project> +   </nova:owner> +   <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/> +   <nova:ports> +    <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340"> +     <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/> +    </nova:port> +   </nova:ports> +  </nova:instance> + </metadata> + <memory unit='KiB'>65536</memory> + <currentMemory unit='KiB'>65536</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> +  <system> +   <entry name='manufacturer'>OpenStack Foundation</entry> +   <entry name='product'>OpenStack Nova</entry> +   <entry name='version'>25.1.0</entry> +   <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='family'>Virtual Machine</entry> +  </system> + </sysinfo> + <os> +  <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type> +  <boot dev='hd'/> +  <smbios mode='sysinfo'/> + </os> + <features> +  <acpi/> +  <apic/> +  <vmcoreinfo state='on'/> + </features> + <cpu mode='host-model' check='partial'> +  <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <clock offset='utc'> +  <timer name='pit' tickpolicy='delay'/> +  <timer name='rtc' tickpolicy='catchup'/> +  <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> +  <emulator>/usr/bin/qemu-system-x86_64</emulator> +  <disk type='file' device='disk'> +   <driver name='qemu' type='qcow2' cache='none'/> +   <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/> +   <target dev='vda' bus='virtio'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +  </disk> +  <controller type='usb' index='0' model='piix3-uhci'> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> +  </controller> +  <controller type='pci' index='0' model='pci-root'/> +  <interface type='hostdev' managed='yes'> +   <mac address='fa:16:3e:aa:d9:23'/> +   <source> +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> +  </interface> +  <serial type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='isa-serial' port='0'> +    <model name='isa-serial'/> +   </target> +  </serial> +  <console type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='serial' port='0'/> +  </console> +  <input type='tablet' bus='usb'> +   <address type='usb' bus='0' port='1'/> +  </input> +  <input type='mouse' bus='ps2'/> +  <input type='keyboard' bus='ps2'/> +  <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> +   <listen type='address' address='0.0.0.0'/> +  </graphics> +  <audio id='1' type='none'/> +  <video> +   <model type='virtio' heads='1' primary='yes'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> +  </video> +  <hostdev mode='subsystem' type='pci' managed='yes'> +   <source> +    <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> +  </hostdev> +  <memballoon model='virtio'> +   <stats period='10'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +  </memballoon> +  <rng model='virtio'> +   <backend model='random'>/dev/urandom</backend> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> +  </rng> + </devices> +</domain> +``` +---- +Simon Jones + diff --git a/results/classifier/105/KVM/1002 b/results/classifier/105/KVM/1002 new file mode 100644 index 00000000..0cce2c82 --- /dev/null +++ b/results/classifier/105/KVM/1002 @@ -0,0 +1,14 @@ +KVM: 0.953 +device: 0.785 +network: 0.681 +graphic: 0.617 +instruction: 0.582 +socket: 0.304 +boot: 0.227 +semantic: 0.164 +mistranslation: 0.071 +vnc: 0.067 +assembly: 0.053 +other: 0.017 + +qemu-system-aarch64: Synchronous Exception with smp > 1 (on M1 running Asahi Linux with KVM) diff --git a/results/classifier/105/KVM/1009 b/results/classifier/105/KVM/1009 new file mode 100644 index 00000000..7fb8f967 --- /dev/null +++ b/results/classifier/105/KVM/1009 @@ -0,0 +1,36 @@ +KVM: 0.990 +network: 0.984 +graphic: 0.959 +instruction: 0.937 +device: 0.888 +boot: 0.824 +semantic: 0.814 +assembly: 0.794 +mistranslation: 0.791 +socket: 0.760 +vnc: 0.759 +other: 0.704 + +Nested KVM Networking Issue (OpenStack) +Description of problem: +Hi, + +Inside openstack i have an instance of Ubuntu 20.04 and i have installed KVM ( using virt-manager ) to setup a Virtual Machine ... i have done that and i created a VM of ubuntu 20.04 inside the Openstack Instance but there are networking issue while i set the default parameter as setting up the VM ( i mean the networking is as default to NAT ) , So when the VM is up and running the PING to 8.8.8.8 is available and also ping to google.com is also valid which shows that the DNS is correctly working ... but there is not connectivity with packages while i do sudo apt update, it will not get any package update and also the wget to google.com is shows that its connected to it but it wont able to download!!! the same happen with curl to any other websites... + + +I'm confirming that the openstack instance has full access to the internet including ping and wget , .... but the VM is not working correctly! + +P.S. I have set the ip forwarding, Iptables , ... also disabled firewals but notting changed!! + + +Would you please fix this ? +Steps to reproduce: +1. creating an openstack instance from ubuntu 20.04 server image +2. updating and upgrading packages setting ip forwarding to 1 ( Enabled), firewall +3. and kernel to 5.13.0.40 and installing virt-manager then reboot +3. creating a VM with default KVM networking ( NAT ) using ubuntu 20.04 server image +4. trying ping, wget, curl , ... + + +Thanks +Best regards diff --git a/results/classifier/105/KVM/1035 b/results/classifier/105/KVM/1035 new file mode 100644 index 00000000..1f71167b --- /dev/null +++ b/results/classifier/105/KVM/1035 @@ -0,0 +1,29 @@ +KVM: 0.969 +other: 0.930 +device: 0.837 +graphic: 0.800 +network: 0.713 +instruction: 0.680 +semantic: 0.546 +boot: 0.427 +socket: 0.372 +vnc: 0.318 +mistranslation: 0.232 +assembly: 0.098 + +Hyper-V on KVM does not work on AMD CPUs +Description of problem: +Can not enable hytper-v on KVM on AMD 3970x +``` +[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +``` +Additional information: +Related issue: +https://bugzilla.kernel.org/show_bug.cgi?id=203477 diff --git a/results/classifier/105/KVM/1042561 b/results/classifier/105/KVM/1042561 new file mode 100644 index 00000000..ae6e978e --- /dev/null +++ b/results/classifier/105/KVM/1042561 @@ -0,0 +1,50 @@ +KVM: 0.794 +device: 0.721 +network: 0.531 +graphic: 0.525 +instruction: 0.507 +semantic: 0.460 +other: 0.455 +socket: 0.448 +boot: 0.388 +vnc: 0.373 +mistranslation: 0.339 +assembly: 0.230 + +Guest has no "xsave" feature with parameter "-cpu qemu64,+xsave" in qemu command line. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:1a577b72475d161b6677c05abe57301362023bb2 +qemu-kvm Commit:98f1f30a89901c416e51cc70c1a08d9dc15a2ad4 +Host Kernel Version:3.5.0-rc1 +Hardware:Romley-EP, Ivy-bridge + + +Bug detailed description: +-------------------------- +Guest has no "xsave" feature when create guest with parameter "-cpu qemu64,+xsave,+avx" in qemu command line, but the guest has avx feature. +When starting a guest with parameter "-cpu host" in qemu command line, the guest has 'avx' and 'xsave' features (as /proc/cpuinfo shows). + +This is not a recent regression; it exists for a long time. + +Reproduce steps: +---------------- +1. qemu-system-x86_64 -m 1024 -smp 2 -hda rhel6u3.img -cpu qemu64,+xsave +2. cat /proc/cpuinfo | grep xsave ( check guest's xsave feature) + +Current result: +---------------- +The guest has no xsave feature + +Expected result: +---------------- +The guest has xsave feature + +Basic root-causing log: + +xsave needs level >= 13, and qemu64 has level=4. Try "-cpu qemu64,+xsave,+avx,level=13". + diff --git a/results/classifier/105/KVM/1045 b/results/classifier/105/KVM/1045 new file mode 100644 index 00000000..68044d51 --- /dev/null +++ b/results/classifier/105/KVM/1045 @@ -0,0 +1,39 @@ +KVM: 0.818 +mistranslation: 0.788 +graphic: 0.763 +semantic: 0.695 +device: 0.570 +instruction: 0.501 +vnc: 0.431 +socket: 0.424 +network: 0.421 +boot: 0.374 +other: 0.238 +assembly: 0.122 + +When a break point is set, nested virtualization sees "kvm_queue_exception: Assertion `!env->exception_has_payload' failed." +Description of problem: +I am debugging XMHF and LHV using QEMU + KVM. I found that if I set a break point using GDB, QEMU will crash when LHV is booting. The message is +``` +qemu-system-i386: ../../../target/i386/kvm/kvm.c:678: kvm_queue_exception: Assertion `!env->exception_has_payload' failed. +``` + +The address of the break point is arbitrary. The break point does not need to hit. So I chose 0 as the address in this bug report. +Steps to reproduce: +1. Start QEMU using `qemu-system-i386 -m 512M -gdb tcp::1234 -smp 2 -cpu Haswell,vmx=yes -enable-kvm -serial stdio -drive media=disk,file=1.img,index=1 -drive media=disk,file=2.img,index=2 -S` +2. In another shell, start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0' --ex c` +3. See many serial output lines. The tail of the output is + ``` + CPU #0: vcpu_vaddr_ptr=0x01e06080, esp=0x01e11000 + CPU #1: vcpu_vaddr_ptr=0x01e06540, esp=0x01e15000 + BSP(0x00): Rallying APs... + BSP(0x00): APs ready, doing DRTM... + LAPIC base and status=0xfee00900 + Sending INIT IPI to all APs... + ``` +4. See assertion error in QEMU + ``` + qemu-system-i386: ../target/i386/kvm/kvm.c:645: kvm_queue_exception: Assertion `!env->exception_has_payload' failed. + ``` +Additional information: +This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216002>. diff --git a/results/classifier/105/KVM/1063807 b/results/classifier/105/KVM/1063807 new file mode 100644 index 00000000..ef288811 --- /dev/null +++ b/results/classifier/105/KVM/1063807 @@ -0,0 +1,86 @@ +KVM: 0.843 +vnc: 0.832 +graphic: 0.818 +instruction: 0.795 +other: 0.792 +boot: 0.773 +device: 0.772 +mistranslation: 0.762 +assembly: 0.746 +semantic: 0.727 +network: 0.684 +socket: 0.630 + +KVM crashes when booting a PointSec encrypted Windows 7 + +Hi all, + +KVM crashes each time the VM boots after installing PointSec. + +Steps to reproduce are: +1) install win7 64bits +2) install PointSec FDE (Full Disk Encryption => http://www.checkpoint.com/products/full-disk-encryption/index.html) +3) regardless any other qemu parameters, one gets a "KVM internal error. Suberror: 1 / emulation failure" error message and a qemu dump like this one: + +KVM internal error. Suberror: 1 +emulation failure +EAX=00000130 EBX=00000000 ECX=00014000 EDX=00050000 +ESI=00000000 EDI=00000000 EBP=00008e3f ESP=0001802d +EIP=000006d3 EFL=00017087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0048 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =25a1 00025a10 0000ffff 00009b00 DPL=0 CS16 [-RA] +SS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0130 00300000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 00028050 00001dd8 +IDT= 00029e40 00000188 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 8e c0 b8 30 01 8e e0 66 b9 00 00 00 00 66 ba 00 00 00 00 <66> 26 67 8b 9a 00 00 05 00 66 64 67 89 1a 66 83 c2 04 66 41 66 81 f9 00 80 01 00 75 e3 0f + + +My system info: +root@RJZ-LNX:/home/rjz# cat /proc/cpuinfo | tail -24 +cpu family : 6 +model : 37 +model name : Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz +stepping : 5 +microcode : 0x2 +cpu MHz : 1199.000 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 2 +apicid : 5 +initial apicid : 5 +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 acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid +bogomips : 5319.72 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + + + +and qemu (Ubuntu distribution) info is: + +root@RJZ-LNX:/home/rjz# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + + + +Best regards, +Rolando. + +Since this is very likely rather a KVM kernel bug than a QEMU userspace bug, could you please report it to the KVM mailing list / bug tracker instead (see http://www.linux-kvm.org/page/Bugs)? Thanks! + diff --git a/results/classifier/105/KVM/1064 b/results/classifier/105/KVM/1064 new file mode 100644 index 00000000..8aa92fec --- /dev/null +++ b/results/classifier/105/KVM/1064 @@ -0,0 +1,56 @@ +KVM: 0.866 +network: 0.771 +device: 0.759 +mistranslation: 0.720 +socket: 0.689 +graphic: 0.647 +instruction: 0.644 +vnc: 0.626 +semantic: 0.567 +boot: 0.469 +assembly: 0.459 +other: 0.445 + +aarch64:qemu6.2.0 compile error +Description of problem: + +Steps to reproduce: +1. download qemu source package +`wget http://mirrors.163.com/centos-vault/centos/8-stream/AppStream/Source/SPackages/qemu-kvm-6.2.0-12.module_el8.7.0%2b1140%2bff0772f9.src.rpm` +2. install qemu source package +`rpm -ivh qemu-*.rpm` +3. build qemu +` rpmbuild --define "_topdir /xxx/src_qemu6.2.0" -bb SPECS/qemu-kvm.spec` +4. error message: +``` +In function 'dump_receive_iov', + inlined from 'filter_dump_receive_iov' at ../net/dump.c:157:5: +../net/dump.c:89:9: error: 'writev' specified size 18446744073709551600 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] + 89 | if (writev(s->fd, dumpiov, cnt + 1) != sizeof(hdr) + caplen) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from /home/xxx/src_qemu6.2.0/BUILD/qemu-kvm-6.2.0/include/qemu/osdep.h:108, + from ../net/dump.c:25: +../net/dump.c: In function 'filter_dump_receive_iov': +/usr/include/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)' + 52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count) + | ^~~~~~ +cc1: all warnings being treated as errors +``` +**gcc version** +``` +# gcc --version +gcc (GCC) 10.3.1 +Copyright (C) 2020 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. +``` +``` +[root]# meson -v +0.62.1 +[root]# ninja -v +ninja: error: loading 'build.ninja': No such file or directory +[root@vm77 src_qemu6.2.0]# ninja --version +1.8.2 +``` +Additional information: + diff --git a/results/classifier/105/KVM/1073952 b/results/classifier/105/KVM/1073952 new file mode 100644 index 00000000..f02c1e18 --- /dev/null +++ b/results/classifier/105/KVM/1073952 @@ -0,0 +1,47 @@ +KVM: 0.943 +device: 0.893 +graphic: 0.675 +vnc: 0.663 +instruction: 0.653 +boot: 0.652 +semantic: 0.617 +network: 0.550 +socket: 0.485 +other: 0.475 +mistranslation: 0.302 +assembly: 0.180 + +data sent to serial interface gets truncated after 64kb + +When sending more than 64kb of data to the serial interface in a short timespan, the data seems to disappear. + +I tested it with the latest release (qemu-kvm-1.2.0-rc2.tar.gz) where the bug still occurs. I stumbled upon it when I upraged my qemu version. The bug did not occur in the last version i had (0.12.5). + +You can reproduce it as follows: + +1. Start a dd or cat command in one terminal and pipe the output to a netcat. The testfile has to be larger than 64kb. I used one that had 93kb and did contain only ascii text. + + $ dd if=<TESTFILE> | nc -l 127.0.0.1 65432 + or + $ cat <TESTFILE> | nc -l 127.0.0.1 65432 + +2. Start a qemu and let the first serial port connect to the listening netcat. I suppose that the testsystem can be any system that does not read from the serial port on its own (e.g. during boot process). I used a self compiled minimal linux. + + $ qemu -cdrom <TESTSYSTEM> -serial tcp:127.0.0.1:65432 + +3. When the testsystem is booted, read from the serial device and write it to a file. + + $ dd if=/dev/ttyS0 of=/tmp/testFile + or + $ cat /dev/ttyS0 > /tmp/testFile + + +The result in almost all of my testruns is, that the /tmp/testFile does only has the size of 64kb. The rest of the data vanished. In some cases the file was slightly bigger (65kb or 67kb) but allways under 70kb. The complete file (93kb) was not trasmitted in any of the runs. + +I hope my explanation is exactly enough for you to reproduce it. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1093360 b/results/classifier/105/KVM/1093360 new file mode 100644 index 00000000..9d816831 --- /dev/null +++ b/results/classifier/105/KVM/1093360 @@ -0,0 +1,31 @@ +KVM: 0.904 +device: 0.847 +other: 0.818 +vnc: 0.763 +graphic: 0.726 +semantic: 0.691 +socket: 0.636 +mistranslation: 0.585 +network: 0.563 +boot: 0.525 +instruction: 0.507 +assembly: 0.337 + +files on microsoft iso images mounted to qemu VM get stripped from Version info. E.G. Microsoft UAG installation fails + +QEMU 0.9.0-0.14.1 +KVM 60-88-0.14.1 +there is a reference for a root cause, why installation of Microsoft UAG fails. +http://blogs.technet.com/b/isablog/archive/2010/07/13/another-tmg-2010-installation-failure-with-error-0x80070643.aspx + +when checking available information on the mounted UAG ISO in my qemu machine, I realized simliar reduced information. +this was found: +using AQEMU 0.8.2 of 2011.07.27 + +using QEMU 0.9.0-0.14.1 and KVM 60-88-0.14.1 +in an KVM managed machine + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/110 b/results/classifier/105/KVM/110 new file mode 100644 index 00000000..330143e7 --- /dev/null +++ b/results/classifier/105/KVM/110 @@ -0,0 +1,14 @@ +KVM: 0.996 +device: 0.910 +network: 0.763 +other: 0.475 +graphic: 0.382 +boot: 0.331 +instruction: 0.309 +semantic: 0.301 +socket: 0.260 +vnc: 0.245 +mistranslation: 0.099 +assembly: 0.069 + +KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on diff --git a/results/classifier/105/KVM/1135567 b/results/classifier/105/KVM/1135567 new file mode 100644 index 00000000..cc203432 --- /dev/null +++ b/results/classifier/105/KVM/1135567 @@ -0,0 +1,51 @@ +KVM: 0.938 +graphic: 0.930 +instruction: 0.894 +semantic: 0.888 +mistranslation: 0.883 +network: 0.881 +device: 0.877 +other: 0.876 +boot: 0.781 +socket: 0.700 +assembly: 0.687 +vnc: 0.666 + +QXL crashes a Windows 7 guest if host goes into screensaver + +Note: if further information is required, I'll be glad to supply it. + +I am using on the host +- HP z800 with 72GB RAM and 2x x5680 +- Gentoo 64-bit host (3.7.9 kernel, FGLRX RADEON driver 13.1) +- LIBVIRT 1.0.2 with QEMU(-KVM) 1.4.0 + +The guest: +- Windows 7 32-bit +- 2GB allocated +- 2 CPU +- using virtio for everything (disk,net,memballoon) +- Display = SPICE with spice channel +- Video driver is qxl (ram says 64MB) +- Spice-guest-tools 0.52 installed + +When I use QXL and have the guest open in Virt-Manager/Virt-Viewer and let the host go into screensaver mode, the Win7 crashes hard. + +When I change video to VGA, it survives the screen saver, no problem at all ,smooth sailing. + +regards + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hello, + +Obviously my hardware configuration and versions etc. have changed. + +Also, I have taken to not using screensavers in the virtual machines anymore i.e. disabled. + +BUT: I have set it up as similarly as possible and the crash/freeze/hang up with current versions of the drivers seems to be gone. + +So I guess the ticket can be closed. + +Thanks for checking! ... so I'm closing this ticket now. + diff --git a/results/classifier/105/KVM/1136 b/results/classifier/105/KVM/1136 new file mode 100644 index 00000000..d08b1801 --- /dev/null +++ b/results/classifier/105/KVM/1136 @@ -0,0 +1,14 @@ +KVM: 0.995 +device: 0.754 +network: 0.667 +instruction: 0.566 +graphic: 0.442 +semantic: 0.275 +boot: 0.271 +vnc: 0.233 +mistranslation: 0.157 +socket: 0.146 +other: 0.143 +assembly: 0.045 + +qemu-system-ppc64: KVM HPT guest sometimes fails to migrate diff --git a/results/classifier/105/KVM/1138 b/results/classifier/105/KVM/1138 new file mode 100644 index 00000000..36f06248 --- /dev/null +++ b/results/classifier/105/KVM/1138 @@ -0,0 +1,14 @@ +KVM: 0.873 +device: 0.692 +instruction: 0.523 +graphic: 0.516 +other: 0.512 +network: 0.490 +semantic: 0.271 +mistranslation: 0.172 +boot: 0.159 +vnc: 0.109 +assembly: 0.022 +socket: 0.017 + +Not able to get KVM in qemu-system-s390x built from 6.2.0 source on Fedora 31 diff --git a/results/classifier/105/KVM/1155 b/results/classifier/105/KVM/1155 new file mode 100644 index 00000000..02130241 --- /dev/null +++ b/results/classifier/105/KVM/1155 @@ -0,0 +1,40 @@ +KVM: 0.861 +instruction: 0.797 +graphic: 0.794 +device: 0.681 +semantic: 0.398 +other: 0.388 +vnc: 0.374 +boot: 0.304 +mistranslation: 0.286 +network: 0.277 +socket: 0.243 +assembly: 0.152 + +RISC-V: Instruction fetch exceptions can have invalid tval/epc combination +Description of problem: +Instruction page fault / guest-page fault / access fault exceptions can have invalid `epc`/`tval` combinations, for example as shown in the debug log: + +``` +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff802fec76, tval:0xffffffff802ff000, desc=guest_exec_page_fault +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000014, epc:0xffffffff80243fe6, tval:0xffffffff80244000, desc=guest_exec_page_fault +``` + +From the privileged spec: + +> If `mtval` is written with a nonzero value when an instruction access-fault or page-fault exception occurs on a system with variable-length instructions, then `mtval` will contain the virtual address of the portion of the instruction that caused the fault, while `mepc` will point to the beginning of the instruction. + +Currently RISC-V only has 32-bit and 16-bit instructions, so the difference `tval - epc` should be either `0` or `2`. In the examples above the differences are `906` and `26` respectively. + +Possibly notable: all occurrences of these invalid combinations to have `tval` aligned to a page-boundary. +Steps to reproduce: +This one only gives invalid `tval`/`epc` combinations with instruction guest-page faults, but I've found it to be the easiest reproducer to describe, since presumably running KVM in RISC-V QEMU is a standard setup. I have not otherwise been able to find a more minimal case. + +1. Start a QEMU-based `riscv64` machine +2. Start a KVM-based virtual machine with QEMU inside it +3. Do some stuff in the KVM-based virtual machine to increase the chance of page faults +4. Look in the debug log of the outer QEMU for `guest_exec_page_fault` exceptions with `tval` ending in `000`, but `epc` ending in neither `000` nor `ffe` + +Everything in both layers of guests should otherwise work without issue, but other/future software that relies on the spec-mandated relationship of `epc`/`tval` may break. +Additional information: + diff --git a/results/classifier/105/KVM/1156632 b/results/classifier/105/KVM/1156632 new file mode 100644 index 00000000..da5d8f4a --- /dev/null +++ b/results/classifier/105/KVM/1156632 @@ -0,0 +1,49 @@ +KVM: 0.966 +socket: 0.940 +device: 0.806 +semantic: 0.731 +graphic: 0.726 +instruction: 0.711 +other: 0.693 +network: 0.541 +mistranslation: 0.401 +vnc: 0.391 +boot: 0.326 +assembly: 0.291 + +not receiving RESET event after system_reset command causes QMP connection to die + +I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection: + +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) close socket +7) Connect to socket -> connection refused + +However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events: +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) Receive reply (is a RESET event) +7) Receive reply (is a RESET event) +8) close socket +9) Connect to socket -> ok + +I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU? + +For what its worth, i'm using Ubuntu 12.10: +kvm --version +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1173490 b/results/classifier/105/KVM/1173490 new file mode 100644 index 00000000..bf53515b --- /dev/null +++ b/results/classifier/105/KVM/1173490 @@ -0,0 +1,41 @@ +KVM: 0.795 +graphic: 0.750 +network: 0.677 +device: 0.589 +instruction: 0.481 +socket: 0.478 +semantic: 0.454 +mistranslation: 0.440 +other: 0.315 +boot: 0.267 +vnc: 0.228 +assembly: 0.130 + +virtio net adapter driver with kvm slow on winxp + +# lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 12.04.1 LTS +Release: 12.04 +Codename: precise + +#virsh version +Compiled against library: libvirt 1.0.4 +Using library: libvirt 1.0.4 +Using API: QEMU 1.0.4 +Running hypervisor: QEMU 1.2.0 + +windows xp clean install with spice-guest-tools-0.52.exe from + http://spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.52.exe + +it comes very slow , and the Interrupts process got very high cpu usage(above 60%). +when i switch the net adapter from virtio to default(rtl8139) ,it works well. + +spice-guest-tools-0.3 works well. +In spice-guest-tools-0.52 and 0.59, svchost.exe will use 50% cpu. + +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/105/KVM/1191326 b/results/classifier/105/KVM/1191326 new file mode 100644 index 00000000..b605002e --- /dev/null +++ b/results/classifier/105/KVM/1191326 @@ -0,0 +1,242 @@ +KVM: 0.538 +device: 0.453 +graphic: 0.437 +other: 0.379 +vnc: 0.379 +instruction: 0.376 +semantic: 0.356 +mistranslation: 0.329 +boot: 0.322 +network: 0.308 +assembly: 0.238 +socket: 0.226 + +QNX 4 doesn't boot on qemu >= 1.3 + + +I am using virtual machine with QNX4 operating system installed on it. I updated my qemu from version +to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I try to use any newer version +(1.3, 1.4, 1.5) QNX4 doesn't boot. I tried on windows and linux ubuntu hosts - effects are the same. + +When virtual machine boots qnx bootloader loads and starts operating system. In the next step +qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem starts when operating system +tries mount partition - an error occur and qnx stop booting procedure: + +mount -p "No bios signature in partition sector on /dev/hd0" + +I have tried install qnx from cdrom but it seems that there is the same problem. QNX installer boot from +cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next step of installation procedure. + +with qemu 1.6 is even worse - qemu crash every time when QNX detects hard disk + +Please use git-bisect to find out which change between 1.2.0 and 1.3.0 broke things for you. + +problem appeared in this commit: + +commit b90600eed3c0efe5f3260853c873caf51c0677b1 +Author: Avi Kivity <email address hidden> +Date: Wed Oct 3 16:42:37 2012 +0200 + + dma: make dma access its own address space + + Instead of accessing the cpu address space, use an address space + configured by the caller. + + Eventually all dma functionality will be folded into AddressSpace, + but we have to start from something. + + Reviewed-by: Anthony Liguori <email address hidden> + Signed-off-by: Avi Kivity <email address hidden> + +Output from valgrind running latest qemu downloaded from git. Qemu crashed of course. +If I can check something more, please let me know. + +==29109== Memcheck, a memory error detector +==29109== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. +==29109== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info +==29109== Command: qemu-system-i386 -no-kvm -hda /home/jq/QNX4.vmdk +==29109== Parent PID: 15280 +==29109== +==29109== Invalid write of size 8 +==29109== at 0x4C2CD8D: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DF292: iov_from_buf (iov.c:37) +==29109== by 0x4E01B8: qemu_iovec_from_buf (iov.c:374) +==29109== by 0x1A0CA6: bdrv_aio_bh_cb (block.c:3820) +==29109== by 0x186CEB: aio_bh_poll (async.c:81) +==29109== by 0x18693D: aio_poll (aio-posix.c:188) +==29109== by 0x1870FA: aio_ctx_dispatch (async.c:205) +==29109== by 0x5081AB4: g_main_context_dispatch (gmain.c:2715) +==29109== by 0x3235CE: glib_pollfds_poll (main-loop.c:189) +==29109== by 0x3236C2: os_host_main_loop_wait (main-loop.c:234) +==29109== by 0x32379A: main_loop_wait (main-loop.c:484) +==29109== by 0x3B0776: main_loop (vl.c:2090) +==29109== Address 0x157c8ff8 is not stack'd, malloc'd or (recently) free'd +==29109== +==29109== Invalid read of size 4 +==29109== at 0x3C4B85: ldl_p (bswap.h:262) +==29109== by 0x3C4CC6: ldl_le_p (bswap.h:295) +==29109== by 0x3CAAC2: address_space_rw (exec.c:1953) +==29109== by 0x3CAE0C: address_space_write (exec.c:2021) +==29109== by 0x3CB570: address_space_unmap (exec.c:2230) +==29109== by 0x1EF736: dma_memory_unmap (dma.h:146) +==29109== by 0x1EFCBD: dma_bdrv_unmap (dma-helpers.c:108) +==29109== by 0x1EFE35: dma_bdrv_cb (dma-helpers.c:146) +==29109== by 0x1A0FE0: bdrv_co_em_bh (block.c:3901) +==29109== by 0x186CEB: aio_bh_poll (async.c:81) +==29109== by 0x18693D: aio_poll (aio-posix.c:188) +==29109== by 0x1870FA: aio_ctx_dispatch (async.c:205) +==29109== Address 0x157ba000 is 0 bytes after a block of size 4,096 alloc'd +==29109== at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DA0AB: qemu_memalign (oslib-posix.c:90) +==29109== by 0x3CB322: address_space_map (exec.c:2162) +==29109== by 0x1EF6BE: dma_memory_map (dma.h:137) +==29109== by 0x1EFEEF: dma_bdrv_cb (dma-helpers.c:156) +==29109== by 0x1F0205: dma_bdrv_io (dma-helpers.c:219) +==29109== by 0x1F027A: dma_bdrv_read (dma-helpers.c:228) +==29109== by 0x2724C4: ide_dma_cb (core.c:676) +==29109== by 0x278AC2: bmdma_cmd_writeb (pci.c:324) +==29109== by 0x2792AA: bmdma_write (piix.c:76) +==29109== by 0x43535C: memory_region_write_accessor (memory.c:440) +==29109== + +valgrind: m_mallocfree.c:266 (mk_plain_bszB): Assertion 'bszB != 0' failed. +valgrind: This is probably caused by your program erroneously writing past the +end of a heap block and corrupting heap metadata. If you fix any +invalid writes reported by Memcheck, this assertion failure will +probably go away. Please try that before reporting this as a bug. + +==29109== at 0x3804C6CF: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3804C812: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38000883: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38057FB1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x38058962: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x380212DC: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3802158F: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3808F1DB: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) +==29109== by 0x3809E68C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) + +sched status: + running_tid=1 + +Thread 1: status = VgTs_Runnable +==29109== at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) +==29109== by 0x4DA0AB: qemu_memalign (oslib-posix.c:90) +==29109== by 0x1A2192: qemu_blockalign (block.c:4375) +==29109== by 0x1A0D92: bdrv_aio_rw_vector (block.c:3842) +==29109== by 0x1A0EB6: bdrv_aio_readv_em (block.c:3861) +==29109== by 0x1A169A: bdrv_co_io_em (block.c:4068) +==29109== by 0x1A172B: bdrv_co_readv_em (block.c:4085) +==29109== by 0x19D921: bdrv_co_do_readv (block.c:2574) +==29109== by 0x1A1091: bdrv_co_do_rw (block.c:3918) +==29109== by 0x1E7776: coroutine_trampoline (coroutine-ucontext.c:118) +==29109== by 0x5F3264F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) +==29109== by 0x7FEFFC5CF: ??? + +Thread 2: status = VgTs_WaitSys +==29109== at 0x5CDB0C1: sem_timedwait (sem_timedwait.S:102) +==29109== by 0x4DAD2A: qemu_sem_timedwait (qemu-thread-posix.c:238) +==29109== by 0x387F22: worker_thread (thread-pool.c:97) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + +Thread 3: status = VgTs_WaitSys +==29109== at 0x5CDB89C: __lll_lock_wait (lowlevellock.S:132) +==29109== by 0x5CDE2B7: _L_cond_lock_874 (pthread_mutex_lock.c:483) +==29109== by 0x5CDE086: __pthread_mutex_cond_lock (pthread_mutex_lock.c:61) +==29109== by 0x5CD8E17: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:236) +==29109== by 0x4DAB68: qemu_cond_wait (qemu-thread-posix.c:116) +==29109== by 0x3BE13E: qemu_tcg_wait_io_event (cpus.c:760) +==29109== by 0x3BE588: qemu_tcg_cpu_thread_fn (cpus.c:891) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + +Thread 4: status = VgTs_WaitSys +==29109== at 0x5CD8D84: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:162) +==29109== by 0x4DAB68: qemu_cond_wait (qemu-thread-posix.c:116) +==29109== by 0x3A38CD: vnc_worker_thread_loop (vnc-jobs.c:222) +==29109== by 0x3A3DF6: vnc_worker_thread (vnc-jobs.c:318) +==29109== by 0x5CD4E99: start_thread (pthread_create.c:308) +==29109== by 0x5FDDCCC: clone (clone.S:112) + + +On Linux hosts are you using KVM? Does it make any difference? + +Is there a freely downloadable image that we can use for debugging? + +Thanks, + +Paolo + +KVM doesnt make any difference. + + +I am also experiencing this problem QNX 4.25 images that were created under 1.0 no longer work when I've upgraded to 2.0 or 2.1 qemu. + +The error message that I receive is the same. The problem is with the virtual disk driver, it performs the initial boat loader, then when the OS goes to load the file system it fails. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + +I've just tried to launch QNX 4.25 ISO bootdisk on qemu-system-x86_64 built from current git. +QEMU screen is skewed (see on screenshot). I tried all different options in -vga key - all the same. + +This is still a problem with QEMU 2.11. + +Note that the problem in #10 is unrelated to the issue (though GUI works for with the the demo floppy). The problem mentioned in this bug is related to a QNX that is already installed to a disk. Unfortunately the QNX demo floppy that was once free and which can be still found on the internet does not allow installation to disk, so it can't be used to reproduce the bug. + +At work we still maintain an application for QNX 4.25 so I can help debugging it, but I don't know where to start. Currently we use VirtualBox and VMware, but I personally would prefer QEMU much more. + +Please let me know if there is any way how I could help to sort this issue out. + +I wonder - would be a record using rr of any help? I can create record for QEMU 1.2.0 where it works and on current QEMU. + +Also, I did a bit of debugging myself around the DMA code as per comment #3 it was introduced in a commit that changed some of the DMA. What I did was that I added some debug printfs [1] to dma_memory_rw() to QEMU 1.2.0 and to QEMU 2.11.1. + +I noticed on thing - there is a big difference between writes between the two versions. +Because this stuff is completely outside my knowledge, I don't know whether this is important or not, but better more information that not enough. For recent versions of QEMU I see a few 16 B writes from address 0x6d10 and addresses close to it which contain some data. Immediately after that there is a ton of 8B writes from addresses starting at 0x102004 which contain zeros only. On the other hand, the QEMU 1.2.0 is missing the initial 16B writes, but then there's even more 8B writes from addresses around 0x102004 which contain some data instead of zeros like in the current version. + +[1] the printf looks like this: + +printf("DEBUG: DMA %s at address %lx %lu bytes: ", ((dir == DMA_DIRECTION_FROM_DEVICE) ? "read" : "write"), addr, len); + +Hi, + +I had the same problem, and maybe it can help. I wrote my own toy OS with a PATA / IDE driver back in 2012 using older version of QEMU and everything worked fine. These days, I tried that on a recent version (2.5) and it failed with exactly the same behaviour - lots of zeros being written during a DMA transfer. + +After some research, I found that the behaviour that was changed with 1.3 is that the bus master configuration bit (bit 2 of the PCI command register) is now emulated, and my driver did not set this bit. Apparently, the BIOS does not set it either, so it was off and the DMA transfer silently failed and only wrote zeros. + +So I added some code to my init routine that sets this bit, and voila - it worked. I have tried 1.2, 1.3 and 2.5.0 and this works with all of them. + +I do not know the internals of QNX, but I learned that apparently also Linux did not set this bit in older version, so it might very well be that QNX does not set it either and this is the issue. + +@Christiat: thank you so much, you are right! I put together a quick hack[1] to seabios to forcefully enable bus master bit on ata device and QNX booted! + +[1] I just added an unconditional call to the pci_enable_busmaster(pci); to the init_pciata() function in ata.c + +It turns out modifying code is not needed at all. The only thing that is needed is to configure SeaBIOS with CONFIG_ATA_DMA=y. + +So the steps needed to make QNX 4 work on current QEMU are +1. Download SeaBIOS source and make sure the configuration has CONFIG_ATA_DMA=y set +2. Build SeaBIOS +3. Run qemu such as "qemu-system-i386 -bios /path/to/seabios/bios.bin -hda qnxdisk ..." + +qemu git master has a prebuilt seabios with CONFIG_ATA_DMA=y now. + +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/105/KVM/1198 b/results/classifier/105/KVM/1198 new file mode 100644 index 00000000..303305cc --- /dev/null +++ b/results/classifier/105/KVM/1198 @@ -0,0 +1,66 @@ +KVM: 0.907 +other: 0.893 +graphic: 0.859 +semantic: 0.850 +device: 0.833 +instruction: 0.811 +mistranslation: 0.798 +assembly: 0.777 +vnc: 0.724 +boot: 0.724 +socket: 0.665 +network: 0.590 + +Windows 11 Guest keeps crashing with abort in cpu_asidx_from_attrs +Steps to reproduce: +1. Create Windows 11 guest, SWTPM, SECBOOT (haven't tested without since this is not an option for installing Windows 11) +2. Use OS +3. Will eventually crash. Have tried across multiple kernels 5.17, 5.18, 5.19 +Additional information: +``` + + Stack trace of thread 76223: + #0 0x00007f24072d44dc n/a (libc.so.6 + 0x884dc) + #1 0x00007f2407284998 raise (libc.so.6 + 0x38998) + #2 0x00007f240726e53d abort (libc.so.6 + 0x2253d) + #3 0x00007f240726e45c n/a (libc.so.6 + 0x2245c) + #4 0x00007f240727d4c6 __assert_fail (libc.so.6 + 0x314c6) + #5 0x0000555681a35101 cpu_asidx_from_attrs (qemu-system-x86_64 + 0x572101) + #6 0x0000555681c6531e cpu_memory_rw_debug (qemu-system-x86_64 + 0x7a231e) + #7 0x0000555681bfb54a x86_cpu_dump_state (qemu-system-x86_64 + 0x73854a) + #8 0x0000555681d84a65 kvm_cpu_exec (qemu-system-x86_64 + 0x8c1a65) + #9 0x0000555681d85e48 kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x8c2e48) + #10 0x0000555681fed0a8 qemu_thread_start (qemu-system-x86_64 + 0xb2a0a8) + #11 0x00007f24072d278d n/a (libc.so.6 + 0x8678d) + #12 0x00007f24073538e4 __clone (libc.so.6 + 0x1078e4) +``` + + +``` +KVM: entry failed, hardware error 0x80000021 + +If you're running a guest on an Intel machine without unrestricted mode +support, the failure can be most likely due to the guest entering an invalid +state for Intel VT. For example, the guest maybe running in big real mode +which is not supported on less recent Intel processors. + +EAX=00000000 EBX=00000000 ECX=00000000 EDX=04c6d3e0 +ESI=12af7eb0 EDI=9e55d420 EBP=821b5aa0 ESP=10db0fb0 +EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =b500 7ffb5000 ffffffff 00809300 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 000fffff 00000000 +TR =0040 10d97000 00000067 00008b00 +GDT= 10d98fb0 00000057 +IDT= 00000000 00000000 +CR0=00050032 CR2=f80ff80c CR3=e47e7000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=qemu-system-x86_64: ../qemu-7.0.0/hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. +2022-09-06 14:48:15.392+0000: shutting down, reason=crashed +``` diff --git a/results/classifier/105/KVM/1201447 b/results/classifier/105/KVM/1201447 new file mode 100644 index 00000000..f03ca992 --- /dev/null +++ b/results/classifier/105/KVM/1201447 @@ -0,0 +1,41 @@ +KVM: 0.978 +device: 0.922 +other: 0.873 +graphic: 0.669 +semantic: 0.630 +mistranslation: 0.623 +instruction: 0.599 +socket: 0.536 +network: 0.462 +vnc: 0.459 +boot: 0.446 +assembly: 0.244 + +Blue screen when disk uses cache='writeback' + +I am running Windows 2008R2 as KVM guest on Ubuntu 12.04 hypervisor. Disk controller and network card are virtio devices with drivers from https://launchpad.net/kvm-guest-drivers-windows/+download (virtio-win-drivers-20120712-1.iso). +Everything worked fine until I changed disk controller cache from the default (writethrough) to writeback. This introduced occasional blue screens. I noticed that they are linked to high disk IO. For example restoring over 1GB of backup files will results in a blue screen on around 4 out of 5 attempts. Also Windows update crashes the system sometimes. When idle the system will run fine for hours or sometimes even days. +After removing cache='writeback' from the config everything came back to normal. + +qemu-kvm: + Installed: 1.0+noroms-0ubuntu14.8 + Candidate: 1.0+noroms-0ubuntu14.8 + Version table: + *** 1.0+noroms-0ubuntu14.8 0 + 500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages + 100 /var/lib/dpkg/status + 1.0+noroms-0ubuntu14.7 0 + 500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages + 1.0+noroms-0ubuntu13 0 + 500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages + + + +Hi Jacek, +I haven't seen other writeback related crashes and the info so far isn't enough to debug anything. + +Did you get any related host logs on the crashes. +In dmesg or the guest log in /var/log/libvirt/qemu/<guestname>.log? + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1202289 b/results/classifier/105/KVM/1202289 new file mode 100644 index 00000000..3765e060 --- /dev/null +++ b/results/classifier/105/KVM/1202289 @@ -0,0 +1,103 @@ +KVM: 0.959 +vnc: 0.958 +instruction: 0.951 +device: 0.946 +assembly: 0.946 +other: 0.943 +semantic: 0.942 +graphic: 0.942 +boot: 0.930 +network: 0.929 +socket: 0.929 +mistranslation: 0.916 + +Windows 2008/7 Guest to Guest Very slow 10-20Mbit/s + +I'm not sure if I'm submitting this to the proper place or not, if not, please direct me accordingly. + +At this point I'm starting to get desperate, I'll take any options or suggestions that spring to mind: + +Anyway, the problem exists on multiple hosts of various quality. From 4 core 8g mem machines to 12 core 64Gig mem machines with LVM and Raid-10. + +Using iperf as the testing utility: (windows guest can be either Windows 7 or 2008R2) +-Windows Guest -> Windows Guest averages 20Mbit/s (The problem) +-Windows Guest -> Host averages 800Mbit/s +-Host -> Windows Guest averages 1.1Gbit/s +-Linux Guest -> Host averages 12GBit/s +-Linux Guest -> Linux Guest averages 10.2Gbit/s + +For windows guests, switching between e1000 and virtio drivers doesn't make much of a difference. + +I use openvswitch to handle the bridging (makes bonding nics much easier) + +Disabling TSO GRO on all the host nics, and virtual nics, as well as modding the registry using: +netsh int tcp set global (various params here) can slightly improve Windows -> windows throughput. up to maybe 100Mbit/s but even that is spotty at best. + +The Particulars of the fastest host which benchmarks about the same as the slowest host. + +Ubuntu 12.04 64bit (updated to lastest as of July 15th) +Linux cckvm03 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux + +libvirt: +Source: libvirt +Version: 0.9.8-2ubuntu17.10 + +qemu-kvm +Package: qemu-kvm +Version: 1.0+noroms-0ubuntu14.8 +Replaces: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0), kvm-data, qemu + +openvswitch +Source: openvswitch +Version: 1.4.0-1ubuntu1.5 + +/proc/cpuifo + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Xeon(R) CPU E5-2440 0 @ 2.40GHz +stepping : 7 +microcode : 0x70d +cpu MHz : 2400.226 +cache size : 15360 KB +physical id : 0 +siblings : 12 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov +pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt +scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap +erfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdc +m pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm +ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid +bogomips : 4800.45 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + + +-Sample KVM line +usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -name gvexch01 -uuid d28ffb4b-d809-3b40-ae3d-2925e6995394 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/gvexch01.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=dc,menu=on -drive file=/dev/vgroup/gvexch01,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/dev/vgroup/gvexch01-d,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=18,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bf:4e:1c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +I'm not sure yet, but I think the TSO problem affects much more setups, not only windows guests. You might try to set GSO to off in windows guests too, if there is such an option (GSO might be a linux kernel feature). + +I currently think that we have similar problems with centos7 hosts and guests as well as with some windows7 guests. + +I also read about similar centos6 problems. There is even a original setup guide for centos6 from redhat, to set "tso off gso off" in the host bridge adapter, when you use virtio. + +This whole topic is disturbingly distributed through several setups. The diagnosis of this problem is far from being trivial. + + +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/105/KVM/1203 b/results/classifier/105/KVM/1203 new file mode 100644 index 00000000..299da36c --- /dev/null +++ b/results/classifier/105/KVM/1203 @@ -0,0 +1,58 @@ +KVM: 0.819 +other: 0.808 +graphic: 0.797 +device: 0.769 +semantic: 0.767 +instruction: 0.760 +mistranslation: 0.746 +boot: 0.746 +assembly: 0.742 +network: 0.722 +socket: 0.712 +vnc: 0.698 + +migrate with block-dirty-bitmap (disk size is big enough) can't be finished +Description of problem: +when disk size is big enough(this case using the 4T,related to the bandwith of migration), migrate the VM with block-dirty-bitmap , +the migration will not be finished! +Steps to reproduce: +1. **Start up the source VM,using the commands**: + +/usr/libexec/qemu-kvm -name guest=i-00001C,debug-threads=on -machine pc,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1 -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0xb -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0xc -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0xd -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0xe -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on -drive file=/datastore/e88e2b29-cd39-4b21-9629-5ef2458f7ddd/c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait + +**Start the dst VM using commands as:** + +/usr/libexec/qemu-kvm -name guest=i-00001C,debug-threads=on -machine pc,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1 -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0xb -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0xc -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0xd -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0xe -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on -drive file=/datastore/e88e2b29-cd39-4b21-9629-5ef2458f7ddd/c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait -incoming tcp:0:3333 + +2. **image info as:** + +image: /datastore/e88e2b29-cd39-4b21-9629-5ef2458f7ddd/c08fee8e-caf4-4217-ab4d-351a021c2c3d + +file format: qcow2 +virtual size: 4.0T (4380866641920 bytes) +disk size: 1.0M +cluster_size: 65536 + +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +3. **Add the bitmap :** {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-09-16-10-23"}} +4. **set the dirty-bitmaps capability** :{ "execute": "migrate-set-capabilities" , "arguments":{"capabilities":[ {"capability":"dirty-bitmaps","state": true }]}} +5. **start migrate ** { "execute": "migrate", "arguments": { "uri": "tcp:10.49.35.23:3333" } } +6. **quert migrate parameters** {"execute":"query-migrate-parameters"} the retrun message : +{"return": {"cpu-throttle-tailslow": false, "xbzrle-cache-size": 67108864, "cpu-throttle-initial": 20, "announce-max": 550, "decompress-threads": 2, "compress-threads": 8, "compress-level": 1, "multifd-channels": 2, "multifd-zstd-level": 1, "announce-initial": 50, "block-incremental": false, "compress-wait-thread": true, "downtime-limit": 300, "tls-authz": "", "multifd-compression": "none", "announce-rounds": 5, "announce-step": 100, "tls-creds": "", "multifd-zlib-level": 1, "max-cpu-throttle": 99, "max-postcopy-bandwidth": 0, "tls-hostname": "", "throttle-trigger-threshold": 50, "max-bandwidth": 134217728, "x-checkpoint-delay": 20000, "cpu-throttle-increment": 10}} + +7. **query-migrate-capabilities** ： +{"execute":"query-migrate-capabilities"} the retrun message : +{"return": [{"state": false, "capability": "xbzrle"}, {"state": false, "capability": "rdma-pin-all"}, {"state": false, "capability": "auto-converge"}, {"state": false, "capability": "zero-blocks"}, {"state": false, "capability": "compress"}, {"state": false, "capability": "events"}, {"state": false, "capability": "postcopy-ram"}, {"state": false, "capability": "x-colo"}, {"state": false, "capability": "release-ram"}, {"state": false, "capability": "return-path"}, {"state": false, "capability": "pause-before-switchover"}, {"state": false, "capability": "multifd"}, {"state": true, "capability": "dirty-bitmaps"}, {"state": false, "capability": "postcopy-blocktime"}, {"state": false, "capability": "late-block-activate"}, {"state": false, "capability": "x-ignore-shared"}, {"state": false, "capability": "validate-uuid"}, {"state": false, "capability": "background-snapshot"}]} + +8. **query the info of migrate** using the command {"execute":"query-migrate"} +{"return": {"expected-downtime": 0, "status": "active", "setup-time": 64, "total-time": 1320361, "ram": {"total": 4295499776, "postcopy-requests": 0, "dirty-sync-count": 7909410, "multifd-bytes": 0, "pages-per-second": 80, "page-size": 4096, "remaining": 0, "mbps": 3.5006399999999998, "transferred": 430971236, "duplicate": 1048569, "dirty-pages-rate": 66, "skipped": 0, "normal-bytes": 357560320, "normal": 87295}}} + +**the state of migrate is always active ,no matter how long it takes.** +The bug is : migration with big block dirty bitmap can not be finished +Additional information: + diff --git a/results/classifier/105/KVM/1215 b/results/classifier/105/KVM/1215 new file mode 100644 index 00000000..31167b51 --- /dev/null +++ b/results/classifier/105/KVM/1215 @@ -0,0 +1,85 @@ +KVM: 0.626 +other: 0.615 +device: 0.614 +graphic: 0.593 +vnc: 0.589 +semantic: 0.587 +instruction: 0.565 +socket: 0.565 +assembly: 0.550 +boot: 0.545 +network: 0.540 +mistranslation: 0.532 + +block-stream qmp command regression in 7.1.0 +Description of problem: +After `block-stream` qmp commands, guest was hanged when using `iothread` option. +According to b1e1af3, there are some change at drain blockdev subtree and strong reference to base node. +We couldn't produce this issue when we reverted the commit. +It seems to be raised by racing acquiring aio_lock between iothread and main thread. +Steps to reproduce: +1. Start Guest with upper command. +2. After started, operate `block-stream` command to qmp socket +``` +echo '{"execute":"qmp_capabilities"}{ + "execute":"block-stream", + "arguments":{ + "job-id":"hangTest", + "device":"vdaFile" + } +}' | sudo nc -U /var/run/monitor_a9b43742-9117-4aae-8887-24bdb017ec20 -N +``` +Additional information: +- gdb debug stack +``` +Thread 1 (Thread 0x7fcfaed84600 (LWP 162409) "qemu-system-x86"): +#0 0x00007fcfaf108e7e in __ppoll (fds=0x5634a9b6b240, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 +#1 0x00005634a7be22dd in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64 +#2 0x00005634a7bc02c9 in fdmon_poll_wait (ctx=0x5634a990eec0, ready_list=0x7ffcb2ce4fb8, timeout=-1) at ../util/fdmon-poll.c:80 +#3 0x00005634a7bbf9c9 in aio_poll (ctx=ctx@entry=0x5634a990eec0, blocking=blocking@entry=true) at ../util/aio-posix.c:660 +#4 0x00005634a7ac849d in bdrv_parent_drained_end_single (c=c@entry=0x5634a9b4bb30) at ../block/io.c:76 +#5 0x00005634a7a98240 in bdrv_replace_child_noperm (childp=0x5634a9b61240, new_bs=0x0, free_empty_child=<optimized out>) at ../block.c:2910 +#6 0x00005634a7a987fe in bdrv_replace_child_tran (childp=<optimized out>, new_bs=<optimized out>, tran=<optimized out>, free_empty_child=<optimized out>) at ../block.c:2444 +#7 0x00005634a7a988bc in bdrv_remove_file_or_backing_child (bs=bs@entry=0x5634a9b5d1f0, child=child@entry=0x5634a9b4bb30, tran=tran@entry=0x5634aa415fc0) at ../block.c:5155 +#8 0x00005634a7a9fac6 in bdrv_remove_file_or_backing_child (tran=0x5634aa415fc0, child=0x5634a9b4bb30, bs=0x5634a9b5d1f0) at ../block.c:5133 +#9 bdrv_set_file_or_backing_noperm (parent_bs=parent_bs@entry=0x5634a9b5d1f0, child_bs=child_bs@entry=0x0, is_backing=is_backing@entry=true, tran=tran@entry=0x5634aa415fc0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3412 +#10 0x00005634a7a9fd04 in bdrv_set_backing_noperm (errp=0x7ffcb2ce5150, tran=0x5634aa415fc0, backing_hd=0x0, bs=0x5634a9b5d1f0) at ../block.c:3449 +#11 bdrv_set_backing_hd (bs=bs@entry=0x5634a9b5d1f0, backing_hd=backing_hd@entry=0x0, errp=errp@entry=0x7ffcb2ce5150) at ../block.c:3461 +#12 0x00005634a7b25e19 in stream_prepare (job=0x5634a9e83da0) at ../block/stream.c:85 +#13 0x00005634a7aa922e in job_prepare (job=0x5634a9e83da0) at ../job.c:837 +#14 job_txn_apply (fn=<optimized out>, job=0x5634a9e83da0) at ../job.c:158 +#15 job_do_finalize (job=0x5634a9e83da0) at ../job.c:854 +#16 0x00005634a7aa9726 in job_exit (opaque=0x5634a9e83da0) at ../job.c:941 +#17 0x00005634a7bd26b4 in aio_bh_call (bh=0x7fcfa0824010) at ../util/async.c:150 +#18 aio_bh_poll (ctx=ctx@entry=0x5634a990eec0) at ../util/async.c:178 +#19 0x00005634a7bbf602 in aio_dispatch (ctx=0x5634a990eec0) at ../util/aio-posix.c:421 +#20 0x00005634a7bd22f2 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320 +#21 0x00007fcfaf3c0d1b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x00005634a7bde7c0 in glib_pollfds_poll () at ../util/main-loop.c:297 +#23 os_host_main_loop_wait (timeout=114194793) at ../util/main-loop.c:320 +#24 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596 +#25 0x00005634a784fdc3 in qemu_main_loop () at ../softmmu/runstate.c:734 +#26 0x00005634a769f9e0 in qemu_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:38 +--Type <RET> for more, q to quit, c to continue without paging-- +#27 0x00007fcfaf019d90 in __libc_start_call_main (main=main@entry=0x5634a769b0c0 <main>, argc=argc@entry=56, argv=argv@entry=0x7ffcb2ce54c8) at ../sysdeps/nptl/libc_start_call_main.h:58 +#28 0x00007fcfaf019e40 in __libc_start_main_impl (main=0x5634a769b0c0 <main>, argc=56, argv=0x7ffcb2ce54c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb2ce54b8) at ../csu/libc-start.c:392 +#29 0x00005634a769f905 in _start () +``` +- iothread gdb stack +``` +Thread 3 (Thread 0x7fcfae47e640 (LWP 162411) "IO iothread1"): +#0 futex_wait (private=0, expected=2, futex_word=0x5634a9b49620) at ../sysdeps/nptl/futex-internal.h:146 +#1 __GI___lll_lock_wait (futex=futex@entry=0x5634a9b49620, private=0) at ./nptl/lowlevellock.c:49 +#2 0x00007fcfaf0880dd in lll_mutex_lock_optimized (mutex=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:48 +#3 ___pthread_mutex_lock (mutex=mutex@entry=0x5634a9b49620) at ./nptl/pthread_mutex_lock.c:128 +#4 0x00005634a7bc25b8 in qemu_mutex_lock_impl (mutex=0x5634a9b49620, file=0x5634a7da2997 "../util/async.c", line=682) at ../util/qemu-thread-posix.c:88 +#5 0x00005634a7bd24a5 in aio_context_acquire (ctx=0x5634a9b495c0) at ../util/async.c:682 +#6 co_schedule_bh_cb (opaque=0x5634a9b495c0) at ../util/async.c:520 +#7 0x00005634a7bd26b4 in aio_bh_call (bh=0x5634a9b494a0) at ../util/async.c:150 +#8 aio_bh_poll (ctx=ctx@entry=0x5634a9b495c0) at ../util/async.c:178 +#9 0x00005634a7bbf754 in aio_poll (ctx=0x5634a9b495c0, blocking=blocking@entry=true) at ../util/aio-posix.c:712 +#10 0x00005634a7a9392a in iothread_run (opaque=opaque@entry=0x5634a9998700) at ../iothread.c:67 +#11 0x00005634a7bc21d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#12 0x00007fcfaf084b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#13 0x00007fcfaf116a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/105/KVM/1224444 b/results/classifier/105/KVM/1224444 new file mode 100644 index 00000000..c726cb15 --- /dev/null +++ b/results/classifier/105/KVM/1224444 @@ -0,0 +1,657 @@ +KVM: 0.799 +mistranslation: 0.735 +vnc: 0.708 +network: 0.577 +boot: 0.557 +semantic: 0.552 +assembly: 0.539 +device: 0.523 +instruction: 0.504 +other: 0.504 +socket: 0.494 +graphic: 0.438 + +virtio-serial loses writes when used over virtio-mmio + +virtio-serial appears to lose writes, but only when used on top of virtio-mmio. The scenario is this: + +/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \ + -global virtio-blk-device.scsi=off \ + -nodefconfig \ + -nodefaults \ + -nographic \ + -M vexpress-a15 \ + -machine accel=kvm:tcg \ + -m 500 \ + -no-reboot \ + -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1001/kernel.27944 \ + -dtb /home/rjones/d/libguestfs/tmp/.guestfs-1001/dtb.27944 \ + -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1001/initrd.27944 \ + -device virtio-scsi-device,id=scsi \ + -drive file=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ + -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1001/root.27944,snapshot=on,id=appliance,cache=unsafe,if=none \ + -device scsi-hd,drive=appliance \ + -device virtio-serial-device \ + -serial stdio \ + -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0 \ + -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ + -append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color' + +After the guest starts up, a daemon writes 4 bytes to a virtio-serial socket. The host side reads these 4 bytes correctly and writes a 64 byte message. The guest never sees this message. + +I enabled virtio-mmio debugging, and this is what is printed (## = my comment): + +## guest opens the socket: +trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0' +virtio_mmio: virtio_mmio_write offset 0x50 value 0x3 +opened the socket, sock = 3 +udevadm settle +## guest writes 4 bytes to the socket: +virtio_mmio: virtio_mmio_write offset 0x50 value 0x5 +virtio_mmio: virtio_mmio setting IRQ 1 +virtio_mmio: virtio_mmio_read offset 0x60 +virtio_mmio: virtio_mmio_write offset 0x64 value 0x1 +virtio_mmio: virtio_mmio setting IRQ 0 +sent magic GUESTFS_LAUNCH_FLAG +## host reads 4 bytes successfully: +main_loop libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG +libguestfs: [14605ms] appliance is up +Guest launched OK. +## host writes 64 bytes to socket: +libguestfs: writing the data to the socket (size = 64) +waiting for next request +libguestfs: data written OK +## hangs here forever with guest in read() call never receiving any data + +I am using qemu from git today (2d1fe1873a984). + +strace -f of qemu when it fails. + +Notes: + + - fd = 6 is the Unix domain socket connected to virtio-serial + - only one 4 byte write occurs to this socket (expected guest -> host communication) + - the socket isn't read at all (even though the library on the other side has written) + - the socket is never added to any poll/ppoll syscall, so it's no wonder that qemu never sees any data on the socket + + +Recall this bug only happens intermittently. This is an strace -f of qemu when it happens to work. + +Notes: + + - fd = 6 is the Unix domain socket + - there are an expected number of recvmsg & writes, all with the correct sizes + - this time qemu adds the socket to ppoll + +I can reproduce this bug on a second ARM machine which doesn't have KVM (ie. using TCG). Note it's still linked to virtio-mmio. + +On 09/12/13 14:04, Richard Jones wrote: + +> + -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0 \ + +Is this a socket that libguestfs pre-creates on the host-side? + +> the socket is never added to any poll/ppoll syscall, so it's no +> wonder that qemu never sees any data on the socket + + +This should be happening: + +qemu_chr_open_socket() [qemu-char.c] + unix_connect_opts() [util/qemu-sockets.c] + qemu_socket() + connect() + qemu_set_nonblock() [util/oslib-posix.c] + qemu_chr_open_socket_fd() + socket_set_nodelay() [util/osdep.c] + io_channel_from_socket() + g_io_channel_unix_new() + tcp_chr_connect() + io_add_watch_poll() + g_source_new() + g_source_attach() + g_source_unref() + qemu_chr_be_generic_open() + +io_add_watch_poll() should make sure the fd is polled starting with the +next main loop iteration. + +Interestingly, even in the "successful" case, there's a slew of ppoll() +calls between connect() returning 6, and the first ppoll() that actually +covers fd=6. + +Laszlo + + +> Is this a socket that libguestfs pre-creates on the host-side? + +Yes it is: +https://github.com/libguestfs/libguestfs/blob/master/src/launch-direct.c#L208 + +You mention a scenario that might cause this. But that appears to be when the socket is opened. Note that the guest did send 4 bytes successfully (received OK at the host). The lost write occurs when the host next tries to send a message back to the guest. + +On 09/16/13 16:39, Richard Jones wrote: +>> Is this a socket that libguestfs pre-creates on the host-side? +> +> Yes it is: +> https://github.com/libguestfs/libguestfs/blob/master/src/launch-direct.c#L208 +> +> You mention a scenario that might cause this. But that appears to be +> when the socket is opened. Note that the guest did send 4 bytes +> successfully (received OK at the host). The lost write occurs when the +> host next tries to send a message back to the guest. + +Which is the first time ever that a GLib event loop context messed up +only for reading would be exposed. + +In other words, if the action + + register fd 6 for reading in the GLib main loop context + +fails, that wouldn't prevent qemu from *writing* to the UNIX domain socket. + +In both traces, the IO-thread (thread-id 8488 in the successful case, +and thread-id 7586 in the failing case) is the one opening / registering +etc. fd 6. The IO-thread is also the one calling ppoll(). + +However, all write(6, ...) syscalls are issued by one of the VCPU +threads (thread-id 8490 in the successful case, and thread-id 7588 in +the failing case). + +Hmmmm. Normally (as in, virtio-pci), when a VCPU thread (running KVM) +executes guest code that sends data to the host via virtio, KVM kicks +the "host notifier" eventfd. + +Once this "host notifier" eventfd is kicked, the IO thread should do: + + virtio_queue_host_notifier_read() + virtio_queue_notify_vq() + vq->handle_output() + handle_output() [hw/char/virtio-serial-bus.c] + do_flush_queued_data() + vsc->have_data() + flush_buf() [hw/char/virtio-console.c] + qemu_chr_fe_write() + ... goes to the unix domain socket ... + +When virtio-mmio is used though, the same seems to happen in VCPU thread: + + virtio_mmio_write() + virtio_queue_notify() + virtio_queue_notify_vq() + ...same as above... + + + +A long shot: + +(a) With virtio-pci: + +(a1) guest writes to virtio-serial port, +(a2) KVM sets the host notifier eventfd "pending", +(a3) the IO thread sees that in the main loop / ppoll(), and copies the +data to the UNIX domain socket (the backend), +(a4) host-side libguestfs reads the data and responds, +(a5) the IO-thread reads the data from the UNIX domain socket, +(a6) the IO-thread pushes the data to the guest. + +(b) with virtio-mmio: + +(b1) guest writes to virtio-serial port, +(b2) the VCPU thread in qemu reads the data (virtio-mmio) and copies it +to the UNIX domain socket, +(b3) host-side libguestfs reads the data and responds, +(b4) the IO-thread is not (yet?) ready to read the data from the UNIX +domain socket. + +I can't quite pin it down, but I think that in the virtio-pci case, the +fact that everything runs through the IO-thread automatically serializes +the connection to the UNIX domain socket (and its addition to the GLib +main loop context) with the message from the guest. Due to the KVM +eventfd (the "host notifier") everything goes through the same ppoll(). +Maybe it doesn't enforce any theoretical serialization, it might just +add a sufficiently long delay that there's never a problem in practice. + +Whereas in the virtio-mmio case, the initial write to the UNIX domain +socket, and the response from host-side libguestfs, runs unfettered. I +imagine something like: + +- (IO thread) connect to socket +- (IO thread) add fd to main loop context +- (guest) write to virtio-serial port +- (VCPU thread) copy data to UNIX domain socket +- (host libguestfs) read req, write resp to UNIX domain socket +- (IO thread) "I should probably check readiness on that socket + sometime" + +I don't know why the IO-thread doesn't get there *eventually*. + +What happens if you add a five second delay to libguestfs, before +writing the response? + +Laszlo + + + +On 16 September 2013 17:13, Laszlo Ersek <email address hidden> wrote: +> Hmmmm. Normally (as in, virtio-pci), when a VCPU thread (running KVM) +> executes guest code that sends data to the host via virtio, KVM kicks +> the "host notifier" eventfd. + +What happens in the virtio-pci without eventfd case? +(eg virtio-pci on a non-x86 host) + +Also, IIRC Alex said they'd had an annoying "data gets lost" +issue with the s390 virtio transports too... + +-- PMM + + +> What happens if you add a five second delay to libguestfs, +> before writing the response? + +No change. Still hangs in the same place. + +On 09/17/13 10:09, Peter Maydell wrote: +> On 16 September 2013 17:13, Laszlo Ersek <email address hidden> wrote: +>> Hmmmm. Normally (as in, virtio-pci), when a VCPU thread (running KVM) +>> executes guest code that sends data to the host via virtio, KVM kicks +>> the "host notifier" eventfd. +> +> What happens in the virtio-pci without eventfd case? +> (eg virtio-pci on a non-x86 host) + +I'm confused. I think Anthony or Michael could answer better. + +There's at least three cases here I guess (KVM + eventfd, KVM without +eventfd (enforceable eg. with the "ioeventfd" property for virtio +devices), and TCG). We're probably talking about the third case. + +I think we end up in + + virtio_pci_config_ops.write == virtio_pci_config_write + virtio_ioport_write() + virtio_queue_notify() + ... the "usual" stuff ... + +As far as I know TCG supports exactly one VCPU thread but that's still +separate from the IO-thread. In that case the above could trigger the +problem similarly to virtio-mmio I guess... + +I think we should debug into GLib, independently of virtio. What annoys +me mostly is the huge number of ppoll()s in Rich's trace between +connecting to the UNIX domain socket and actually checking it for +read-readiness. The fd in question should show up in the first ppoll() +after connect(). + +My email might not make any sense. Sorry. +Laszlo + + +> There's at least three cases here I guess (KVM + eventfd, KVM without +> eventfd (enforceable eg. with the "ioeventfd" property for virtio +> devices), and TCG). We're probably talking about the third case. + +To clarify on this point: I have reproduced this bug on two different ARM +machines, one using KVM and one using TCG. + +In both cases they are ./configure'd without any special ioeventfd-related +options, which appears to mean CONFIG_EVENTFD=y (in both cases). + +In both cases I'm using a single vCPU. + +On 09/17/13 11:51, Richard Jones wrote: +>> There's at least three cases here I guess (KVM + eventfd, KVM without +>> eventfd (enforceable eg. with the "ioeventfd" property for virtio +>> devices), and TCG). We're probably talking about the third case. +> +> To clarify on this point: I have reproduced this bug on two different ARM +> machines, one using KVM and one using TCG. +> +> In both cases they are ./configure'd without any special ioeventfd-related +> options, which appears to mean CONFIG_EVENTFD=y (in both cases). +> +> In both cases I'm using a single vCPU. +> + +I think I have a theory now; it's quite convoluted. + +The problem is a deadlock in ppoll() that is *masked* by unrelated file +descriptor traffic in all of the apparently working cases. + +I wrote some ad-hoc debug patches, and this is the log leading up to the +hang: + + io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:0 + qemu_poll_ns: timeout=4281013151888 + poll entry #0 fd 3 + poll entry #1 fd 5 + poll entry #2 fd 0 + poll entry #3 fd 11 + poll entry #4 fd 4 + trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0' + opened the socket, sock = 3 + udevadm settle + libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG + libguestfs: [21734ms] appliance is up + Guest launched OK. + libguestfs: writing the data to the socket (size = 64) + sent magic GUESTFS_LAUNCH_FLAG + main_loop waiting for next request + libguestfs: data written OK + <HANG> + +Setup call tree for the backend (ie. the UNIX domain socket): + + 1 qemu_chr_open_socket() [qemu-char.c] + 2 unix_connect_opts() [util/qemu-sockets.c] + 3 qemu_socket() + 4 connect() + 5 qemu_chr_open_socket_fd() [qemu-char.c] + 6 io_channel_from_socket() + 7 g_io_channel_unix_new() + 8 tcp_chr_connect() + 9 io_add_watch_poll() + 10 g_source_new() + 11 g_source_attach() + +This part connects to libguestfs's UNIX domain socket (the new socket +file descriptor, returned on line 3, is fd 6), and it registers a few +callbacks. Notably, the above doesn't try to add fd 6 to the set of +polled file descriptors. + + +Then, the setup call tree for the frontend (the virtio-serial port) is +as follows: + + 12 virtconsole_initfn() [hw/char/virtio-console.c] + 13 qemu_chr_add_handlers() [qemu-char.c] + +This reaches into the chardev (ie. the backend referenced by the +frontend, label "channel0"), and sets further callbacks. + + +The following seems to lead up to the hang: + + 14 os_host_main_loop_wait() [main-loop.c] + 15 glib_pollfds_fill() + 16 g_main_context_prepare() + 17 io_watch_poll_prepare() [qemu-char.c] + 18 chr_can_read() [hw/char/virtio-console.c] + 19 virtio_serial_guest_ready() [hw/char/virtio-serial-bus.c] + 20 + 21 if (use_multiport(port->vser) && !port->guest_connected) { + 22 return 0; + 23 } + 24 + 25 virtqueue_get_avail_bytes() + 26 g_io_create_watch() // conditionally + 27 qemu_poll_ns() [qemu-timer.c] + 28 ppoll() + +Line 15: glib_pollfds_fill() prepares the array of file descriptors for +polling. As first step, + +Line 16: it calls g_main_context_prepare(). This GLib function runs the +"prepare" callbacks for the GSource's in the main context. + +The GSource for fd 6 has been allocated on line 10 above, and its +"prepare" callback has been set to io_watch_poll_prepare() there. It is +called on line 17. + +Line 17: io_watch_poll_prepare() is a crucial function. It decides +whether fd 6 (the backend fd) will be added to the set of pollfds or +not. + +It checks whether the frontend has become writeable (ie. it must have +been unwriteable up to now, but it must be writeable now). If so, a +(persistent) watch is created (on line 26), which is the action that +includes fd 6 in the set of pollfds after all. If there is no change in +the status of the frontend, the watch is not changed. + +io_watch_poll_prepare() checks for the writeability of the frontend (ie. +virtio serial port) by the "fd_can_read" callback. This has been set to +chr_can_read() on line 13, inside virtconsole_initfn(). + +So, the frontend-writeability check happens in chr_can_read(), which +simply calls: + +Line 19: virtio_serial_guest_ready(). This function *normally* checks +for the available room in the virtqueue (the guest receives serial port +data from the host by submitting "receive requests" that must be filled +in by the host); see line 25. + +However, virtio_serial_guest_ready() first verifies whether the guest +has connected to the virtio-serial port at all. If not, then the +function will report the frontend unwriteable (lines 21-23). + + +Now, right before the hang, the guest hasn't yet connected to the +virtio-serial port. Therefore line 22 fires (= virtio-serial port is +unwriteable), which in turn results in *no* watch being created for the +backend. Consequently, the UNIX domain socket (fd 6) is not added to the +set of pollfds: + + io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:0 + qemu_poll_ns: timeout=4281013151888 + poll entry #0 fd 3 + poll entry #1 fd 5 + poll entry #2 fd 0 + poll entry #3 fd 11 + poll entry #4 fd 4 + +At this point the IO thread is blocked in ppoll(). + +Then, the guest connects to the serial port, and sends data. + + trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0' + opened the socket, sock = 3 + udevadm settle + +As discussed before, this guest-to-host transfer is handled by the VCPU +thread, and the data is written to fd 6 (the UNIX domain socket). The +host-side libguestfs component reads it, and answers. + + libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG + libguestfs: [21734ms] appliance is up + Guest launched OK. + libguestfs: writing the data to the socket (size = 64) + sent magic GUESTFS_LAUNCH_FLAG + main_loop waiting for next request # note, this is a libguestfs message! + libguestfs: data written OK + <HANG> + +Unfortunately, ppoll() is not watching out for fd 6 at all, hence this +deadlocks. + + +What about the successful cases though? A good proportion of the +attempts succeed. + +This is explained by the fact that *other* file descriptors can break +out the IO-thread from ppoll(). + +- The most common example is KVM *with* eventfd support. The KVM eventfd + (the host notifier) is part of the pollfd set, and whenever the guest + sends some data, KVM kicks the eventfd, and ppoll() returns. This + masks the problem universally. + +- In the other two cases, we either have KVM *without* eventfd support, + or TCG. Rich reproduced the hang under both, and he's seen successful + (actually: masked deadlock) cases as well, on both. + + In these setups the file descriptor traffic that masks the problem is + not from a KVM eventfd, hence the wakeup is quite random. There is + sometimes a perceivable pause between ppoll() going to sleep and + waking up. At other times there's no other fd traffic, and the + deadlock persists. + +In my testing on Rich's ARM box, the unrelated fd that breaks out the IO-thread +from ppoll() is the eventfd that belongs to the AIO thread pool. It is fd 11, +and it is allocated in: + + 0x00512d3c in event_notifier_init (e=0x1f4ad80, active=0) at util/event_notifier-posix.c:34 + 34 ret = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); + (gdb) n + 39 if (ret >= 0) { + (gdb) print ret + $2 = 11 + (gdb) where + #0 event_notifier_init (e=0x1f4ad80, active=0) at util/event_notifier-posix.c:39 + #1 0x00300b4c in thread_pool_init_one (pool=0x1f4ad80, ctx=0x1f39e18) at thread-pool.c:295 + #2 0x00300c6c in thread_pool_new (ctx=0x1f39e18) at thread-pool.c:313 + #3 0x0001686c in aio_get_thread_pool (ctx=0x1f39e18) at async.c:238 + #4 0x0006f9d8 in paio_submit (bs=0x1f4a020, fd=10, sector_num=0, qiov=0xbe88c164, nb_sectors=4, + cb=0x389d8 <bdrv_co_io_em_complete>, opaque=0xb6505ec4, type=1) at block/raw-posix.c:799 + #5 0x0006fb84 in raw_aio_submit (bs=0x1f4a020, sector_num=0, qiov=0xbe88c164, nb_sectors=4, + cb=0x389d8 <bdrv_co_io_em_complete>, opaque=0xb6505ec4, type=1) at block/raw-posix.c:828 + #6 0x0006fc28 in raw_aio_readv (bs=0x1f4a020, sector_num=0, qiov=0xbe88c164, nb_sectors=4, + cb=0x389d8 <bdrv_co_io_em_complete>, opaque=0xb6505ec4) at block/raw-posix.c:836 + #7 0x00038b2c in bdrv_co_io_em (bs=0x1f4a020, sector_num=0, nb_sectors=4, iov=0xbe88c164, is_write=false) + at block.c:3957 + #8 0x00038bf0 in bdrv_co_readv_em (bs=0x1f4a020, sector_num=0, nb_sectors=4, iov=0xbe88c164) at block.c:3974 + #9 0x000349d4 in bdrv_co_do_readv (bs=0x1f4a020, sector_num=0, nb_sectors=4, qiov=0xbe88c164, flags=(unknown: 0)) + at block.c:2619 + #10 0x00033804 in bdrv_rw_co_entry (opaque=0xbe88c0e8) at block.c:2236 + #11 0x0009ba54 in coroutine_trampoline (i0=32811528, i1=0) at coroutine-ucontext.c:118 + #12 0x492fd160 in setcontext () from /usr/lib/libc.so.6 + #13 0x492fd160 in setcontext () from /usr/lib/libc.so.6 + Backtrace stopped: previous frame identical to this frame (corrupt stack?) + +And the transitory hang looks like: + + io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:0 + qemu_poll_ns: timeout=4281193192443 + poll entry #0 fd 3 + poll entry #1 fd 5 + poll entry #2 fd 0 + poll entry #3 fd 11 + poll entry #4 fd 4 + +Again, at this point IO thread is blocked in ppoll(), + + trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0' + opened the socket, sock = 3 + udevadm settle + +the guest transferred out some data, + + libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG + libguestfs: [20921ms] appliance is up + Guest launched OK. + libguestfs: writing the data to the socket (size = 64) + sent magic GUESTFS_LAUNCH_FLAG + main_loop waiting for next request + libguestfs: data written OK + +and the host side libguestfs has responded. The IO-thread is blocked in +ppoll(), guaranteed, and it doesn't notice readiness of fd 6 for +reading. + +However, the (completely unrelated) AIO thread-pool eventfd is kicked at +that point, and poll returns: + + ppoll(): 1, errno=Success + poll entry #0 fd 3 events 25 revents 0 + poll entry #1 fd 5 events 1 revents 0 + poll entry #2 fd 0 events 1 revents 0 + poll entry #3 fd 11 events 1 revents 1 + poll entry #4 fd 4 events 1 revents 0 + +Which in turn allows the IO-thread to run os_host_main_loop_wait() +again, and *now* we're seeing the activation of fd 6 (its frontend, the +virtio-serial port has been connected by the guest in the meantime and +is now writeable): + + io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:1 + qemu_poll_ns: timeout=0 + poll entry #0 fd 3 + poll entry #1 fd 5 + poll entry #2 fd 0 + poll entry #3 fd 11 + poll entry #4 fd 4 + poll entry #5 fd 6 + +And stuff works as expected from here on. + + +The VCPU thread needs to interrupt the IO-thread's ppoll() call +explicitly. + +Basically, when the chardev's attached frontend (in this case, the +virtio serial port) experiences a change that would cause it to report +writeability in io_watch_poll_prepare() -- lines 17-18 --, it must +interrupt ppoll(). + +The following call tree seems relevant, but I'm not sure if it would be +appropriate. When the guest message + + trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0' + +is printed, the following call chain is executed in the VCPU thread: + + #0 qemu_chr_fe_set_open (chr=0xf22190, fe_open=1) at qemu-char.c:3404 + #1 0x001079dc in set_guest_connected (port=0x1134f00, guest_connected=1) at hw/char/virtio-console.c:83 + #2 0x003cfd94 in handle_control_message (vser=0x1124360, buf=0xb50005f8, len=8) + at /home/rjones/d/qemu/hw/char/virtio-serial-bus.c:379 + #3 0x003d0020 in control_out (vdev=0x1124360, vq=0x11246b0) at /home/rjones/d/qemu/hw/char/virtio-serial-bus.c:416 + #4 0x0044afe4 in virtio_queue_notify_vq (vq=0x11246b0) at /home/rjones/d/qemu/hw/virtio/virtio.c:720 + #5 0x0044b054 in virtio_queue_notify (vdev=0x1124360, n=3) at /home/rjones/d/qemu/hw/virtio/virtio.c:726 + #6 0x00271f30 in virtio_mmio_write (opaque=0x11278c8, offset=80, value=3, size=4) at hw/virtio/virtio-mmio.c:264 + #7 0x00456aac in memory_region_write_accessor (mr=0x1128ba8, addr=80, value=0xb5972b08, size=4, shift=0, + mask=4294967295) at /home/rjones/d/qemu/memory.c:440 + #8 0x00456c90 in access_with_adjusted_size (addr=80, value=0xb5972b08, size=4, access_size_min=1, + access_size_max=4, access=0x4569d0 <memory_region_write_accessor>, mr=0x1128ba8) + at /home/rjones/d/qemu/memory.c:477 + #9 0x0045955c in memory_region_dispatch_write (mr=0x1128ba8, addr=80, data=3, size=4) + at /home/rjones/d/qemu/memory.c:984 + #10 0x0045cee0 in io_mem_write (mr=0x1128ba8, addr=80, val=3, size=4) at /home/rjones/d/qemu/memory.c:1748 + #11 0x0035d8dc in address_space_rw (as=0xa982f8 <address_space_memory>, addr=471008336, buf=0xb6f3d028 "\003", + len=4, is_write=true) at /home/rjones/d/qemu/exec.c:1954 + #12 0x0035ddf0 in cpu_physical_memory_rw (addr=471008336, buf=0xb6f3d028 "\003", len=4, is_write=1) + at /home/rjones/d/qemu/exec.c:2033 + #13 0x00453000 in kvm_cpu_exec (cpu=0x1097020) at /home/rjones/d/qemu/kvm-all.c:1665 + #14 0x0034ca94 in qemu_kvm_cpu_thread_fn (arg=0x1097020) at /home/rjones/d/qemu/cpus.c:802 + #15 0x494c6bc0 in start_thread () from /usr/lib/libpthread.so.0 + +Unfortunately, the leaf (ie. qemu_chr_fe_set_open()) doesn't do anything +here; the only chardev that sets the "chr_set_fe_open" callback is the +spicevmc backend. + +I think the "socket" chardev might want to implement "chr_set_fe_open", +kicking a (new) global eventfd, sending some signal to the IO-thread, or +interrupting ppoll() in some other way. A new global eventfd just for +this purpose seems quite the kludge, but it shouldn't be hard to +implement. It needs no handler at all. + +Thanks +Laszlo + + + +FWIW I am able to reproduce this quite easily on aarch64 too. + +My test program is: +https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/qemu-speed-test.c + +and you use it like this: +qemu-speed-test --virtio-serial-upload + +(You can also test virtio-serial downloads and a few other things, but those don't appear to deadlock) + +Slowing down the upload, even just by enabling debugging, is sufficient to make the problem go away most of the time. + +I am testing with qemu from git (f45c56e0166e86d3b309ae72f4cb8e3d0949c7ef). + +I don't know how to close bugs in launchpad, but this one can be closed +for a couple of reasons: + +(1) I benchmarked virtio-mmio the other day using qemu-speed-test on aarch64 +and I did not encounter the bug. + +(2) aarch64 has supported virtio-pci for a while, for virtio-mmio is effectively +obsolete. + +Fixed upstream, see previous comment. + diff --git a/results/classifier/105/KVM/1243639 b/results/classifier/105/KVM/1243639 new file mode 100644 index 00000000..79db5805 --- /dev/null +++ b/results/classifier/105/KVM/1243639 @@ -0,0 +1,127 @@ +KVM: 0.697 +mistranslation: 0.641 +vnc: 0.623 +other: 0.609 +device: 0.582 +instruction: 0.550 +graphic: 0.530 +semantic: 0.507 +boot: 0.483 +assembly: 0.452 +network: 0.442 +socket: 0.427 + +qemu-1.5.3 segment fault with -vga qxl + +execute " qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl " on shell will get segment fault after a few seconds if I don't connect to it with spicec client immediately. + +IF excute "spicec -h 127.0.0.1 -p 5900 " immediately !!!! after the qemu-system-x86_64 execution, then no segment fault happens and it runs well. + +===================== + +GDB output: + +root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64 +GNU gdb (GDB) 7.4.1-debian +(gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl + +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff3737700 (LWP 14797)] +[New Thread 0x7ffff2d54700 (LWP 14798)] +[New Thread 0x7ffff0fff700 (LWP 14799)] + +Program received signal SIGSEGV, Segmentation fault. +0x00007ffff683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 +(gdb) bt +#0 0x00007ffff683ad70 in pixman_image_get_data () from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 +#1 0x000055555581060a in surface_data (s=0x5555566183a0) at /zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235 +#2 0x0000555555818616 in vga_draw_graphic (s=0x55555662c778, full_update=1) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788 +#3 0x0000555555818c6a in vga_update_display (opaque=0x55555662c778) at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917 +#4 0x000055555580eb15 in qxl_hw_update (opaque=0x55555662bd70) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766 +#5 0x00005555557bd6bc in graphic_hw_update (con=0x555556618d00) at ui/console.c:254 +#6 0x00005555557c8426 in qemu_spice_display_refresh (ssd=0x55555662c418) at ui/spice-display.c:417 +#7 0x000055555580eff0 in display_refresh (dcl=0x55555662c420) at /zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886 +#8 0x00005555557c0cb1 in dpy_refresh (s=0x555556618370) at ui/console.c:1436 +#9 0x00005555557bd3af in gui_update (opaque=0x555556618370) at ui/console.c:192 +#10 0x0000555555797f20 in qemu_run_timers (clock=0x5555565b5a30) at qemu-timer.c:394 +#11 0x0000555555798183 in qemu_run_all_timers () at qemu-timer.c:453 +#12 0x0000555555760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470 +#13 0x00005555557cd19c in main_loop () at vl.c:2029 +#14 0x00005555557d43f2 in main (argc=13, argv=0x7fffffffe2b8, envp=0x7fffffffe328) at vl.c:4419 +(gdb) + + +====================== + +http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2 +http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2 +spice compiling + ./configure --enable-smartcard=no && make + +qemu-1.5.3 +compiling + ./configure \ +--disable-strip --enable-debug \ +--target-list=x86_64-softmmu,x86_64-linux-user \ +--disable-sdl --audio-drv-list=alsa --disable-vnc --disable-xen --disable-libiscsi \ + --disable-seccomp --disable-glusterfs --disable-libssh2 --disable-smartcard-nss \ + --disable-usb-redir --disable-brlapi --disable-curl --disable-bsd-user \ + \ +--enable-kvm --enable-spice --enable-system --enable-guest-agent --enable-vhost-net + + +root@kali-john:~# qemu-system-x86_64 -version +QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard + +/usr/local/bin/qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sda -vga qxl + +will give same error + +a funny thing: + +if I change the "-drive file=/dev/sda" to "-drive file=/dev/sdb" , it will not run into "segment fault". + +The different between sda & sdb is as following: + linux is installed on /dev/sda and /dev/sdb is another physical hard driver. + +================================================================= + +When change /dev/sda to /dev/sdb , it works well as following: + +(gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sdb --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl +The program being debugged has been started already. +Start it from the beginning? (y or n) y + +Starting program: /usr/local/bin/qemu-system-x86_64 -enable-kvm -machine accel=kvm:tcg -m 1G -drive file=/dev/sdb --full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl +warning: Could not load shared library symbols for linux-vdso.so.1. +Do you need "set solib-search-path" or "set sysroot"? +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff3737700 (LWP 15056)] +[New Thread 0x7ffff2d54700 (LWP 15057)] +[New Thread 0x7ffff0fff700 (LWP 15058)] +[Thread 0x7ffff3737700 (LWP 15056) exited] + +--- No segment fault error any more !! + +It will run into segment fault with /dev/sda but without -vga qxl + + +The qemu & the Host linux OS is iinstalled on /dev/sda + +sorry to mistake + +======== + +The truth is that + +t will NOT run into segment fault with /dev/sda but without -vga qxl + +The qemu & the Host linux OS is iinstalled on /dev/sda + + +Triaging old bug tickets ... QEMU 1.5 is quite old already - can you still reproduce the crash with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1253777 b/results/classifier/105/KVM/1253777 new file mode 100644 index 00000000..c7fbb086 --- /dev/null +++ b/results/classifier/105/KVM/1253777 @@ -0,0 +1,101 @@ +semantic: 0.936 +KVM: 0.922 +mistranslation: 0.913 +assembly: 0.909 +device: 0.905 +instruction: 0.905 +vnc: 0.900 +graphic: 0.897 +network: 0.887 +other: 0.881 +socket: 0.874 +boot: 0.839 + +OpenBSD VM running on OpenBSD host has sleep calls taking twice as long as they should + +Running a script like + +while [ 1 ] +do + date + sleep 1 +done + +on the VM will result in the (correct) date being displayed, but it is displayed only every two (!) seconds. We have also noticed that if we connect to the VM's console using VNC, and move the mouse pointer constantly in the VNC window, the script runs normally with updates every second! Note that the script doesn't have to be running on the VM's console - it's also possible to (say) ssh to the VM from a separate machine and run the script and it will display the '2 second' issue, but as soon as you move the mouse pointer constantly in the VNC console window the script starts behaving normally with updates every second. + +I have only seen this bug when running an OpenBSD VM on an OpenBSD host. Running an OpenBSD VM on a Linux host does not exhibit the problem for me. I also belive (am told) that a Linux VM running on an OpenBSD host does not exhibit the problem. + +I have been using the OpenBSD 5.4 64 bit distro which comes with qemu 1.5.1 in a package, however I tried compiling qemu 1.6.1 and that has the same bug. In fact older OpenBSD distros have the same issue - going back to OpenBSD distros from two years ago still have the problem. This is not a 'new' bug recently introduced. + +Initially I wondered if it could be traced to an incorrectly set command line option, but I've since gone through many of the options in the man page simply trying different values (eg. different CPU types ( -cpu) , different emulated PC (-M)) but so far the problem remains. + +I'm quite happy to run tests in order to track this bug down better. We use qemu running on OpenBSD extensively and find it very useful! + +Hi, please test qemu 1.7.0-rc. There were several changes to the timer machinery that can help this bug. + +I'll have a look at it now. + +Regards, + +-Martin + + +On 28/11/13 01:58, Paolo Bonzini wrote: +> Hi, please test qemu 1.7.0-rc. There were several changes to the timer +> machinery that can help this bug. +> + + +-- +R A Ward Ltd. | We take the privacy of our customers seriously. +Christchurch | All sensitive E-Mail attachments MUST be encrypted. +New Zealand + + + +I downloaded 1.7.0-rc2 and compiled it. Running it, I see the version +number reported as 1.6.92!? + +In any case, I don't see any improvement, ie. the bug is still there. + +Regards, + +-Martin + + +On 28/11/13 01:58, Paolo Bonzini wrote: +> Hi, please test qemu 1.7.0-rc. There were several changes to the timer +> machinery that can help this bug. +> + + + +Hadn't heard any news on this bug so decided to check the latest source. 1.7.0 now available so downloaded it and compiled it. No mean feat in itself for OpenBSD. FWIW it seemed a lot more difficult than for earlier (1.6.x) versions. 1.7.0 now reports its version as 1.7.0 - a good start. Alas the "2 second" bug still appears to be there. + +This issue was fixed in the openstack/python-tripleoclient 0.0.10 release. + +What does comment #5 mean? Is this issue now fixed with the latest version of QEMU? + +I hadn't seen comment #5. Not sure how that affects qemu. +Unfortunately I'm not in a position to set up a system any time soon +with the latest versions of everything to see if the bug is still present. + + +On 24/01/17 08:32, Thomas Huth wrote: +> What does comment #5 mean? Is this issue now fixed with the latest +> version of QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + +-- +R A Ward Ltd. | We take the privacy of our customers seriously. +Christchurch | All sensitive E-Mail attachments MUST be encrypted. +New Zealand + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1259499 b/results/classifier/105/KVM/1259499 new file mode 100644 index 00000000..ef27a49e --- /dev/null +++ b/results/classifier/105/KVM/1259499 @@ -0,0 +1,85 @@ +KVM: 0.811 +mistranslation: 0.775 +instruction: 0.742 +other: 0.742 +network: 0.740 +device: 0.733 +vnc: 0.720 +boot: 0.719 +graphic: 0.712 +assembly: 0.709 +socket: 0.705 +semantic: 0.636 + +QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64 + +I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state. + +Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message: + +$ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $? +error: operation failed: Error -22 while loading VM state +1 + +I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again. + +This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-( + +Here is the command being run by libvirt: + +/usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c-17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -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=0x6 -loadvm wtb + +ipxe-qemu 1.0.0+git-20120202.f6840ba-3 +qemu 1.7.0+dfsg-2 +qemu-keymaps 1.7.0+dfsg-2 +qemu-slof 20130430+dfsg-1 +qemu-system 1.7.0+dfsg-2 +qemu-system-arm 1.7.0+dfsg-2 +qemu-system-common 1.7.0+dfsg-2 +qemu-system-mips 1.7.0+dfsg-2 +qemu-system-misc 1.7.0+dfsg-2 +qemu-system-ppc 1.7.0+dfsg-2 +qemu-system-sparc 1.7.0+dfsg-2 +qemu-system-x86 1.7.0+dfsg-2 +qemu-user 1.7.0+dfsg-2 +qemu-utils 1.7.0+dfsg-2 +libvirt-bin 1.1.4-2 +libvirt0 1.1.4-2 +libvirtodbc0 6.1.6+dfsg-4 + +Hi Francois, + I've managed to reproduce this, in my log file (/var/log/libvirt/qemu/machinename.log) I see: + +Unknown ramblock "0000:02.0/qxl.vram", cannot accept migration +qemu: warning: error while loading state for instance 0x0 of device 'ram' +qemu-system-x86_64: Error -22 while loading VM state + +do you also see that unknown ramblock warning? + +(I'm running on F20 using 1.6.0 and 1.7.0 qemu's built from source running minimal F20 guests) + +Dave + +Hi Francois, + I've done some more digging. +It looks like the problem you've hit is related to the same one that's fixed by: + +http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00513.html + +however that only fixes older restores ; there is a work around which is to pass to QEMU: + +-global i440FX-pcihost.short_root_bus=1 + +on loading the snapshot; which can be done by editing the snapshot xml files - but is obviously a bit +messy. + +Thanks for digging into this. +I am indeed getting the same ramblock error. So it's good that there appears to be a fix for it. +Also if I understand it correctly this particular issue only affects the 1.6.0 snapshots so given that most of my snapshots are still on 1.3.x a direct upgrade to 1.7+ will hopefully let me avoid the issue. + +Yes, my understanding of the bug is that 1.7+ should load your 1.3.x images and then snapshots taken on 1.7.x should be OK into the future. + +I don't think there's currently a way of fixing those 1.6.0 snapshots; that workaround will let you load them in 1.7, but I think if you were then to take a snapshot on 1.7 with that flag, the snapshot would have the same problem. + +Setting status to "Won't fix" since there is no good solution to this problem according to comment #4. + diff --git a/results/classifier/105/KVM/1268596 b/results/classifier/105/KVM/1268596 new file mode 100644 index 00000000..74751897 --- /dev/null +++ b/results/classifier/105/KVM/1268596 @@ -0,0 +1,66 @@ +KVM: 0.972 +vnc: 0.960 +other: 0.955 +instruction: 0.953 +device: 0.944 +graphic: 0.938 +mistranslation: 0.937 +semantic: 0.929 +socket: 0.893 +network: 0.882 +boot: 0.864 +assembly: 0.838 + +Compilation Error: hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function + +Qemu git-cloned from mo. 13.01.14 (ca. 13:00 GMT), Version 1.7.50 + + +#git clone git://git.qemu-project.org/qemu.git +# cd qemu; git submodule update --init dtc +#./configure --disable-xen --enable-kvm +...No Errors... + +#CC="ccache gcc" make -j8 +.... + GEN qemu.1 + Signing optionrom/kvmvapic.bin + GEN qemu-img.1 + CC qapi-types.o +hw/virtio/dataplane/vring.c: In function ‘vring_pop’: +hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function [-Werror=uninitialized] +cc1: all warnings being treated as errors +make: *** [hw/virtio/dataplane/vring.o] Error 1 +make: *** Waiting for unfinished jobs.... + + +Thx. + + + +What compiler is this? The variable is quite obviously initialized before that line. + +On 13 January 2014 14:40, Paolo Bonzini <email address hidden> wrote: +> What compiler is this? The variable is quite obviously initialized +> before that line. + +The issue is that one of the code paths has a shadowing declaration +of 'ret' which is what gets assigned to, and so in that code path +the compiler is correct that the outer 'ret' is not assigned to. + +Stefan said he was going to send out a fix for this. + +thanks +-- PMM + + +A fix has been posted to the mailing list and will soon be merged into qemu.git: + +http://thread.gmane.org/gmane.comp.emulators.qemu/250657 + +Thanks a lot. + +Fix had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=385c04d0b66917457b6 +... thus marking this ticked as fixed. + diff --git a/results/classifier/105/KVM/1288259 b/results/classifier/105/KVM/1288259 new file mode 100644 index 00000000..af38d8c2 --- /dev/null +++ b/results/classifier/105/KVM/1288259 @@ -0,0 +1,65 @@ +KVM: 0.863 +graphic: 0.620 +mistranslation: 0.495 +device: 0.439 +other: 0.418 +socket: 0.341 +vnc: 0.324 +instruction: 0.302 +assembly: 0.276 +semantic: 0.261 +network: 0.223 +boot: 0.179 + +KVM vms are paused and cannot be deleted due to hardware error 0x0 + +Upon creation of instances via OpenStack nova api instances got stuck in spawning state. Then, after trying to delete instances they got stuck in deleting state. After investigation the following error was found: + +KVM: entry failed, hardware error 0x0 +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000623 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 000f0000 0000ffff 0000f300 +SS =0000 00000000 0000ffff 0000f300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=28 95 66 ba 01 4a 03 00 66 89 d8 66 5b 66 5e e9 15 79 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +All instances were in paused state: +root@node-7:~# virsh list +setlocale: No such file or directory + Id Name State +---------------------------------------------------- + 4 instance-00000004 paused + 5 instance-00000005 paused + 6 instance-00000006 paused + 7 instance-00000007 paused + 8 instance-00000008 paused + 9 instance-00000009 paused + +The only way to delete VM is to reset it and then resume it. After this, VM is deleted properly. +OpenStack version: Havana on Ubuntu 12.04 +KVM version: QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu7.12.10, Debian), Copyright (c) 2003-2008 Fabrice Bellard + + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Thanks Thomas for reassigning this to Ubuntu. +That would look like an issue with the KVM HW support, but is too long ago for anything reasonable to be done. + +If this still is an issue please describe what you encounter and add current logs. +Marking incomplete for now. + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1294227 b/results/classifier/105/KVM/1294227 new file mode 100644 index 00000000..3d253b6b --- /dev/null +++ b/results/classifier/105/KVM/1294227 @@ -0,0 +1,45 @@ +KVM: 0.796 +semantic: 0.592 +other: 0.579 +device: 0.489 +network: 0.419 +graphic: 0.414 +mistranslation: 0.334 +vnc: 0.332 +socket: 0.318 +instruction: 0.280 +boot: 0.163 +assembly: 0.054 + +migration wrong handling of KVM_GET_DIRTY_LOG ioctl + +In the code below kvm_vm_ioctl(...) can return --errno != -1 from ioctl call, but return only checks for -1. +Found during KVM-ARM migration which apperead to go through but was actually failing getting +memslot dirty bitmap. + +static int kvm_physical_sync_dirty_bitmap(....) +{ + .... + if(kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) { + - err out + } + ... continue +} + +Sent patch for error handling: +http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg05633.html + +The apparently obvious fix was applied as commit b533f658a98325d0e4 but then reverted in commit 50212d6346f33d6e19, because not all errno returns from this ioctl should be treated as errors. + +That commit message said "Revert that patch instead of fixing it properly this late in the release process. I disagree with this approach, but let's make things move _somewhere_, instead of arguing endlessly whch of the 2 proposed fixes is better." -- and then we never did a proper fix, so 5 years later we're still making an incorrect == -1 check... + + + +Moving this bug back to Confirmed to move it out of "In progress" state. We still check for only -1 upstream. + +Yet another try to fix this issue: +https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07557.html + +Patch has been merged here: +https://gitlab.com/qemu-project/qemu/-/commit/38e0b7904eca7cd32 + diff --git a/results/classifier/105/KVM/1307281 b/results/classifier/105/KVM/1307281 new file mode 100644 index 00000000..5acd3515 --- /dev/null +++ b/results/classifier/105/KVM/1307281 @@ -0,0 +1,28 @@ +KVM: 0.722 +vnc: 0.580 +other: 0.561 +mistranslation: 0.559 +instruction: 0.518 +device: 0.513 +network: 0.509 +graphic: 0.503 +socket: 0.497 +boot: 0.488 +semantic: 0.484 +assembly: 0.455 + +qemu crash with assertion in usb_packet_complete_one + +qemu release verison: 1.7.1 +guest os : win7 32bits +qemu cmdline: +/usr/bin/qemu-system-x86_64 -name hch_test -S -machine pc-i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=12,threads=2 -uuid 5ad433c9-e490-42f3-b365-c30d756fbd70 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hch_test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -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 virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/opt/cvm/hch_test/hch_test.inst,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/data/hugedisk/hch_test/hch_test_share.add,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f2:05:b7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/hch_test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -spice port=5903,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0 + +i use spice to connect to vm and utilize usb redirection. i plug a u-disk into a remote computer and start copy a big file (3G+) to u-disk and qemu was crashed in the middle of the transmission. + +i check the qemu log and found this log: "qemu-system-x86_64: hw/usb/core.c:438: usb_packet_complete_one: Assertion `p->stream || ((&ep->queue)->tqh_first) == p' failed". this crash can be reproduced every time. + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1307656 b/results/classifier/105/KVM/1307656 new file mode 100644 index 00000000..56401350 --- /dev/null +++ b/results/classifier/105/KVM/1307656 @@ -0,0 +1,70 @@ +KVM: 0.580 +other: 0.567 +vnc: 0.549 +mistranslation: 0.539 +instruction: 0.469 +assembly: 0.436 +device: 0.435 +graphic: 0.432 +boot: 0.421 +network: 0.410 +socket: 0.405 +semantic: 0.398 + +qemu segfault when starting virt-manager + +libvirtd 1.2.3 +virt-manager 1.0.1 +qemu 1.7.92 (2.0.0-rc2) + +1. Initially virt-manager is NOT running + +2. I start a VM manually using "virsh start ...", causing a qemu instance to be run as + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name Zeus_Virtualized -S -machine pc-i440fx-2.0,accel=kvm,usb=off -cpu Penryn -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 6384b4d2-1c58-4595-bce2-b248230e2c9c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Zeus_Virtualized.monitor,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 -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_USBStick.qcow2,if=none,id=drive-usb-disk0,format=qcow2 -device usb-storage,drive=drive-usb-disk0,id=usb-disk0,removable=off -drive file=/home/pief/isos/openSUSE-13.1-DVD-x86_64.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_HDD1.qcow2,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 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_HDD2.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/home/pief/libvirt VMs/Zeus_Virtualized_SSD.qcow2,if=none,id=drive-virtio-disk2,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk2,id=virtio-disk2,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 + +3. I start virt-manager (just starting it, nothing special). + +4. The qemu instance segfaults with the attached backtrace. + + + + + +No crash BTW if virt-manager is started first and THEN "virsh start..." is executed. + +Judging by the backtrace this is the bug fixed by commit 92b3eeadd9bc, which is in current git master and will be in the imminent 2.0.0-rc3. + + +Fix is already queued for qemu 2.0 GA + +commit 92b3eeadd9bc72f1f4e5ba1f62a289dc0190e88f +Author: Cole Robinson <email address hidden> +Date: Thu Apr 10 14:47:38 2014 -0400 + + qom: Fix crash with qom-list and link properties + + +On 04/14/14 20:47, Pieter Hollants wrote: +> Public bug reported: +> +> libvirtd 1.2.3 +> virt-manager 1.0.1 +> qemu 1.7.92 (2.0.0-rc2) + +I think this should be fixed by Cole's patch, in rc3: + +commit 92b3eeadd9bc72f1f4e5ba1f62a289dc0190e88f +Author: Cole Robinson <email address hidden> +Date: Thu Apr 10 14:47:38 2014 -0400 + + qom: Fix crash with qom-list and link properties + +http://thread.gmane.org/gmane.comp.emulators.qemu/266588 + +Laszlo + + + +Yep, confirm it's fixed in rc3. + diff --git a/results/classifier/105/KVM/1312668 b/results/classifier/105/KVM/1312668 new file mode 100644 index 00000000..1bd9955e --- /dev/null +++ b/results/classifier/105/KVM/1312668 @@ -0,0 +1,71 @@ +instruction: 0.979 +KVM: 0.936 +device: 0.908 +graphic: 0.873 +socket: 0.829 +boot: 0.807 +vnc: 0.756 +mistranslation: 0.732 +other: 0.677 +network: 0.638 +semantic: 0.623 +assembly: 0.343 + +x86 cpu nx feature: guest reboots after migrate exec + +Using instruction on +http://www.linux-kvm.org/page/Migration +I save VM state to external file and try load it, but VM starts, shows saved screen and reboots immediatly. + +Cmdline for vm state saving: + +$ sudo ./i386-softmmu/qemu-system-i386 -machine accel=kvm,kernel_irqchip=on -enable-kvm -m 512 -hda image.raw -vga std -net none -M pc -monitor stdio -cpu SandyBridge +(or -cpu "n270" , or "kvm32,+sse2,+pae,+nx") + +Monitor cmd: +(qemu) stop +(qemu) migrate_set_speed 4095m +(qemu) migrate "exec:gzip -c > STATEFILE.gz" +(qemu) q + +Cmdline for vm state loading: + +$ sudo ./i386-softmmu/qemu-system-i386 -machine accel=kvm,kernel_irqchip=on -enable-kvm -m 512 -hda image.raw -vga std -net none -M pc -monitor stdio -cpu SandyBridge -incoming "exec: gzip -c -d STATEFILE.gz" +(or -cpu "n270" , or "kvm32,+sse2,+pae,+nx") + +If I do the same without NX cpu feature (-cpu option "n270,-nx" / "SandyBridge,-nx" / "kvm32,+pae,+sse2") or on qemu-system-x86_64, VM save/load works correctly. + +Log kvm-all.c, DEBUG_KVM=y: + +QEMU 2.0.0 monitor - type 'help' for more information +(qemu) kvm_init_vcpu +...handle_io.../...handle_mmio... +kvm_cpu_exec() +shutdown +kvm_cpu_exec() +interrupt exit requested +io window exit +kvm_cpu_exec() + +Host: + + $ lsb_release -rd + Description: Ubuntu 12.04.4 LTS + Release: 12.04 + + $ uname -a + Linux <username> 3.8.0-38-generic #56~precise1 SMP Tue Apr 22 12:46:44 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux + +Guest: + 1. Ubuntu 12.04 32bit + 2. WIndows 8 32bit + +Qemu: v2.0.0 +commit a9e8aeb3755bccb7b51174adcf4a3fc427e0d147 +Author: Peter Maydell <email address hidden> +Date: Thu Apr 17 13:41:45 2014 +0100 + +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/105/KVM/1344 b/results/classifier/105/KVM/1344 new file mode 100644 index 00000000..f24659c8 --- /dev/null +++ b/results/classifier/105/KVM/1344 @@ -0,0 +1,14 @@ +KVM: 0.977 +instruction: 0.692 +device: 0.674 +graphic: 0.650 +semantic: 0.648 +mistranslation: 0.550 +other: 0.528 +boot: 0.393 +vnc: 0.147 +network: 0.119 +socket: 0.025 +assembly: 0.005 + +custom kernel give me KVM internal error. Suberror: 4 diff --git a/results/classifier/105/KVM/1352179 b/results/classifier/105/KVM/1352179 new file mode 100644 index 00000000..4ff6a760 --- /dev/null +++ b/results/classifier/105/KVM/1352179 @@ -0,0 +1,46 @@ +KVM: 0.838 +device: 0.763 +graphic: 0.688 +instruction: 0.686 +semantic: 0.552 +socket: 0.525 +assembly: 0.496 +mistranslation: 0.481 +network: 0.459 +vnc: 0.345 +boot: 0.320 +other: 0.293 + +could not open disk image + +After restart the server it's show this error: + +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +qemu-kvm: -drive file=/var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk: No such file or directory + +the disk info show + qemu-img info disk +image: disk +file format: qcow2 +virtual size: 100G (107374182400 bytes) +disk size: 22G +cluster_size: 65536 +backing file: /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f + +but this file (backing file : /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f) is empty. +And all the instances cant't find the disk image + +We use CentOS release 6.5 (64bit) +kernel version : 2.6.32-431.11.2.el6.x86_64 +qemu-kvm-0.12.1.2-2.415.el6_5.10.x86_64 + +virsh version +Compiled against library: libvirt 0.10.2 +Using library: libvirt 0.10.2 +Using API: QEMU 0.10.2 +Running hypervisor: QEMU 0.12.1 + +Triaging old bug tickets ... can you still reproduce this problem with the latest release of QEMU? how did you create the disk image? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1353149 b/results/classifier/105/KVM/1353149 new file mode 100644 index 00000000..345a9275 --- /dev/null +++ b/results/classifier/105/KVM/1353149 @@ -0,0 +1,52 @@ +KVM: 0.969 +mistranslation: 0.956 +socket: 0.898 +semantic: 0.896 +instruction: 0.884 +other: 0.745 +graphic: 0.680 +device: 0.657 +vnc: 0.563 +boot: 0.553 +network: 0.515 +assembly: 0.393 + +qemu 2.1.0 fails to start if number of cores is greater than 1. + +qemu (kvm) 2.1.0 (built from sources) fails to start if number of cores is greater than 1. + +relevant part of commandline arguments: + +/usr/bin/qemu-system-x86_64 -name test3 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Westmere -m 4096 -realtime mlock=off -smp 1,maxcpus=4,sockets=1,cores=4,threads=1 + +the error reported is: + +qemu-system-x86_64: /home/asavah/pkgbuild/qemu-2.1.0/hw/i386/smbios.c:825: smbios_get_tables: Assertion `smbios_smp_sockets >= 1' failed. +2014-08-05 21:45:35.825+0000: shutting down + +however setting 4 sockets with 1 core each allows me to start the machine just fine. + +the system is debian wheezy +Linux hostname 3.16.0-hostname2 #2 SMP Mon Aug 4 17:02:16 EEST 2014 x86_64 GNU/Linux + +libvirt 1.2.7 (built from sources) + +-smp 1,maxcpus=4,sockets=1,cores=4,threads=1 + +should be + +-smp 4,maxcpus=4,sockets=1,cores=4,threads=1 + +although more human-friendly error is more appropriate there (better than a silent fallback to either 1- or 4- core topology) + +I forgot to mention that VM was created and managed remotely via virt-manager 0.9.5 from another host. +I used custom cpu topology. + +however this config worked fine on qemu 2.0.0 with virt-manager 0.9.5 + +just tried virt-manager 1.0.1 - it creates the proper argument -smp 4,maxcpus=4,sockets=1,cores=4,threads=1 + +so this was a virt-manager bug already fixed upstream. + +this bug can be closed :) + diff --git a/results/classifier/105/KVM/1383857 b/results/classifier/105/KVM/1383857 new file mode 100644 index 00000000..f4fece68 --- /dev/null +++ b/results/classifier/105/KVM/1383857 @@ -0,0 +1,211 @@ +KVM: 0.888 +device: 0.787 +vnc: 0.752 +instruction: 0.731 +boot: 0.715 +other: 0.703 +assembly: 0.694 +semantic: 0.688 +network: 0.687 +graphic: 0.678 +mistranslation: 0.674 +socket: 0.644 + +aarch64: virtio disks don't show up in guest (neither blk nor scsi) + +kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +qemu from git today + +When I create a guest with virtio-scsi disks, they don't show up inside the guest. +Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +no messages about disks, and of course nothing else works. + +Really long command line (generated by libvirt): + +HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none TMPDIR=/home/rjones/d/libguestfs/tmp /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib/guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-reboot -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-serial0 -usb -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -serial unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -msg timestamp=on + +There are no kernel messages about the disks, they just are not seen. + +Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +qemu bug, but I've no idea where to report those. + +On 21 October 2014 20:07, Richard Jones <email address hidden> wrote: +> Public bug reported: +> +> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +> qemu from git today +> +> When I create a guest with virtio-scsi disks, they don't show up inside the guest. +> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +> no messages about disks, and of course nothing else works. + +> There are no kernel messages about the disks, they just are not seen. +> +> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +> qemu bug, but I've no idea where to report those. + +Yeah, "regressed with this newer kernel" sounds more like a kernel +bug than a QEMU bug to me, especially if all the other virt devices +still work. + +-- PMM + + +I have now also tried virtio-blk and that doesn't work either. Same symptoms: no log messages at all (even with ignore_loglevel), and no disks appear. + +> Yeah, "regressed with this newer kernel" sounds more like a kernel +> bug than a QEMU bug to me, especially if all the other virt devices +> still work. + +It seems like no virtio drivers work, but it's very hard to tell when your guest has no disks and therefore no operating system. How can I debug this further? + +On 21 October 2014 22:15, Richard Jones <email address hidden> wrote: +> I have now also tried virtio-blk and that doesn't work either. Same +> symptoms: no log messages at all (even with ignore_loglevel), and no +> disks appear. +> +>> Yeah, "regressed with this newer kernel" sounds more like a kernel +>> bug than a QEMU bug to me, especially if all the other virt devices +>> still work. +> +> It seems like no virtio drivers work, but it's very hard to tell when +> your guest has no disks and therefore no operating system. How can I +> debug this further? + +Oh. I assumed from the fact your commandline had other virtio +devices and you were only complaining about virtio-scsi that it +was a single-backend issue. + +Suggestions: + * bisect the kernel to find out when it broke + * add a bunch of debug printks to the kernel to find out why + it's not finding the disks. The logging here is terrible IMHO: + the kernel usually detects a specific problem and then throws + all this info away in favour of just silently deciding there's + no hardware there + +thanks +-- PMM + + +On 21 October 2014 22:33, Peter Maydell <email address hidden> wrote: +> Suggestions: + +...you might also try asking on <email address hidden>, which +is where the KVM/ARM kernel devs hang out, to see if somebody +else has seen this. + +-- PMM + + +Finally finished the git bisect (of the guest kernel, not qemu): + +421520ba98290a73b35b7644e877a48f18e06004 is the first bad commit +commit 421520ba98290a73b35b7644e877a48f18e06004 +Author: Yalin Wang <email address hidden> +Date: Fri Sep 26 03:07:09 2014 +0100 + + ARM: 8167/1: extend the reserved memory for initrd to be page aligned + + This patch extends the start and end address of initrd to be page aligned, + so that we can free all memory including the un-page aligned head or tail + page of initrd, if the start or end address of initrd are not page + aligned, the page can't be freed by free_initrd_mem() function. + + Signed-off-by: Yalin Wang <email address hidden> + Acked-by: Catalin Marinas <email address hidden> + Signed-off-by: Russell King <email address hidden> + +:040000 040000 23bd54d302533c173a4ae592969dd2868794e9ed f1833b44ee7a389902f6f9d2fb55f4b89ba0de16 M arch + +Now might be a good time to mention that Fedora has very recently switched to using 64k pages. + +I'll continue this on the mailing list you suggested. + +Still happening with latest upstream kernel. It seems to involve using the -initrd option at all, with any cpio file, even a tiny one. More results posted here: + +https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012557.html + +Finally found the problem, patch posted: +https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html + +I was just about to get to testing this stuff, but thanks for working +through it on your own, and apologies I didn't get to it before. + +Cc'ing Marc so he's aware of the progress. + +-Christoffer + +On Mon, Dec 1, 2014 at 3:46 PM, Richard Jones <email address hidden> wrote: +> Finally found the problem, patch posted: +> https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1383857 +> +> Title: +> aarch64: virtio disks don't show up in guest (neither blk nor scsi) +> +> Status in QEMU: +> New +> +> Bug description: +> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +> qemu from git today +> +> When I create a guest with virtio-scsi disks, they don't show up inside the guest. +> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +> no messages about disks, and of course nothing else works. +> +> Really long command line (generated by libvirt): +> +> HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none +> TMPDIR=/home/rjones/d/libguestfs/tmp +> /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs- +> oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m +> 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +> a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config +> -nodefaults -chardev +> socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib +> /guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon +> chardev=charmonitor,id=monitor,mode=control -rtc +> base=utc,driftfix=slew -no-reboot -boot strict=on -kernel +> /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd +> /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append +> panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel +> efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 +> no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory +> root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device +> virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio- +> serial0 -usb -drive +> file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id +> =drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi- +> hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive- +> scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive +> file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id +> =drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi- +> hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive- +> scsi0-0-1-0,id=scsi0-0-1-0 -serial +> unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock +> -chardev +> socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock +> -device virtserialport,bus=virtio- +> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 +> -msg timestamp=on +> +> There are no kernel messages about the disks, they just are not seen. +> +> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +> qemu bug, but I've no idea where to report those. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1383857/+subscriptions + + +Richard -- I assume we fixed this one way or another, right? + + +Oh yes, long fixed. + diff --git a/results/classifier/105/KVM/139 b/results/classifier/105/KVM/139 new file mode 100644 index 00000000..da437498 --- /dev/null +++ b/results/classifier/105/KVM/139 @@ -0,0 +1,14 @@ +KVM: 0.905 +network: 0.865 +other: 0.831 +mistranslation: 0.807 +device: 0.795 +instruction: 0.646 +semantic: 0.489 +graphic: 0.383 +boot: 0.341 +vnc: 0.323 +socket: 0.286 +assembly: 0.042 + +kvm rbd driver (and maybe others, i.e. qcow2, qed and so on) does not report DISCARD-ZERO flag diff --git a/results/classifier/105/KVM/1398 b/results/classifier/105/KVM/1398 new file mode 100644 index 00000000..8dc10390 --- /dev/null +++ b/results/classifier/105/KVM/1398 @@ -0,0 +1,19 @@ +KVM: 0.979 +device: 0.901 +instruction: 0.703 +graphic: 0.696 +boot: 0.519 +mistranslation: 0.486 +semantic: 0.402 +vnc: 0.252 +other: 0.207 +socket: 0.164 +assembly: 0.069 +network: 0.052 + +Kernel Fault in primary space mode while using user ASCE emulating s390x with AlmaLinux release 9.1 (Lime Lynx) +Description of problem: +Happens twice during startup, however the system keeps running. +Steps to reproduce: +1. Install Alma Linux s390x on in KVM on x86_64 +2. Start KVM diff --git a/results/classifier/105/KVM/1399191 b/results/classifier/105/KVM/1399191 new file mode 100644 index 00000000..ef5faa40 --- /dev/null +++ b/results/classifier/105/KVM/1399191 @@ -0,0 +1,1189 @@ +KVM: 0.780 +other: 0.770 +graphic: 0.767 +assembly: 0.749 +semantic: 0.739 +instruction: 0.735 +device: 0.733 +mistranslation: 0.732 +vnc: 0.712 +boot: 0.701 +network: 0.680 +socket: 0.670 + +Large VHDX image size + +We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + +Why is that the VHDX generates large sized images for both the formats? + +The following commands were used to convert the vmdk image to VHDX format + +1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk Test-fixed.vhdx + +qemu-img info Test-fixed.vhdx +image: Test-fixed.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + + + +2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + +qemu-img info Test-dynamic.vhdx +image: Test-dynamic.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + +We tried this with the following version of qemu +1. qemu-2.0.0 +2. qemu-2.1.2 +3. qemu-2.2.0-rc4 + + +Please let us know how to create compact VHDX images using qemu-img. +Thank you + +On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> Public bug reported: +> +> We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> +> Why is that the VHDX generates large sized images for both the formats? +> +> The following commands were used to convert the vmdk image to VHDX +> format + +Jeff, did you fix this recently in commit +85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +.bdrv_has_zero_init to bdrv_has_zero_init_1")? + +Stefan + + +On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > Public bug reported: +> > +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> +> Jeff, did you fix this recently in commit +> 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> +> Stefan + + + +Yes, although there has been a report that there are issues in the +resulting vhdx image in a MS server, after this patch. I am going to +test and fix (if confirmed) once my MSDN subscription is renewed (in +process now, I expect it anytime). + +Jeff + + +Please find comments inline + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jeff Cody +Sent: Wednesday, January 07, 2015 9:11 PM +To: Lokesha, Amulya +Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size + +On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > Public bug reported: +> > +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> +> Jeff, did you fix this recently in commit +> 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> +> Stefan + + +Yes, although there has been a report that there are issues in the resulting vhdx image in a MS server, after this patch. I am going to test and fix (if confirmed) once my MSDN subscription is renewed (in process now, I expect it anytime). + +Jeff + +-- + +Hi Jeff, + +Could you please give us a possible timeline of when fix will be available. Our customers are waiting on this as we are blocked with the image creation. + +Thanks, +Amulya + + +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/1399191 + +Title: + Large VHDX image size + +Status in QEMU: + New + +Bug description: + We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. + We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + + Why is that the VHDX generates large sized images for both the + formats? + + The following commands were used to convert the vmdk image to VHDX + format + + 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk + Test-fixed.vhdx + + qemu-img info Test-fixed.vhdx + image: Test-fixed.vhdx + file format: vhdx + virtual size: 50G (53687091200 bytes) + disk size: 50G + cluster_size: 16777216 + + + + 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + + qemu-img info Test-dynamic.vhdx + image: Test-dynamic.vhdx + file format: vhdx + virtual size: 50G (53687091200 bytes) + disk size: 50G + cluster_size: 16777216 + + + We tried this with the following version of qemu + 1. qemu-2.0.0 + 2. qemu-2.1.2 + 3. qemu-2.2.0-rc4 + + + Please let us know how to create compact VHDX images using qemu-img. + Thank you + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + +On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> Please find comments inline +> +> -----Original Message----- +> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jeff Cody +> Sent: Wednesday, January 07, 2015 9:11 PM +> To: Lokesha, Amulya +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > Public bug reported: +> > > +> > > We are trying to convert a VMDK image to VHDX image for deploy +> > > to HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > converting the image using both 'fixed' as well as 'dynamic' +> > > format. We found that both the disks occupy the same size of +> > > 50GB. When the same is done with VHD image, we found that the +> > > dynamic disks are much lesser in size (5 GB) than the fixed disk +> > > (50GB). +> > > +> > > Why is that the VHDX generates large sized images for both the +> > > formats? +> > > +> > > The following commands were used to convert the vmdk image to +> > > VHDX format +> > +> > Jeff, did you fix this recently in commit +> > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > +> > Stefan +> +> +> Yes, although there has been a report that there are issues in the +> resulting vhdx image in a MS server, after this patch. I am going +> to test and fix (if confirmed) once my MSDN subscription is renewed +> (in process now, I expect it anytime). +> +> Jeff +> +> -- +> +> Hi Jeff, +> +> Could you please give us a possible timeline of when fix will be +> available. Our customers are waiting on this as we are blocked with +> the image creation. +> +> Thanks, Amulya + +Hi Amulya, + +I have my MSDN stuff sorted out now, so give me a day or two get my +test machine up and running & testing. + +-Jeff +> +> +> You received this bug notification because you are subscribed to the bug report. +> https://bugs.launchpad.net/bugs/1399191 +> +> Title: +> Large VHDX image size +> +> Status in QEMU: +> New +> +> Bug description: +> We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> +> Why is that the VHDX generates large sized images for both the +> formats? +> +> The following commands were used to convert the vmdk image to VHDX +> format +> +> 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> Test-fixed.vhdx +> +> qemu-img info Test-fixed.vhdx +> image: Test-fixed.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> +> 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx +> +> qemu-img info Test-dynamic.vhdx +> image: Test-dynamic.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> We tried this with the following version of qemu +> 1. qemu-2.0.0 +> 2. qemu-2.1.2 +> 3. qemu-2.2.0-rc4 +> +> +> Please let us know how to create compact VHDX images using qemu-img. +> Thank you +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + + + +-----Original Message----- +From: Jeff Cody [mailto:<email address hidden>] +Sent: Tuesday, January 13, 2015 9:18 AM +To: Lokesha, Amulya +Cc: Bug 1399191; Geoffroy, Daniel +Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size + +On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> Please find comments inline +> +> -----Original Message----- +> From: <email address hidden> [mailto:<email address hidden>] On Behalf +> Of Jeff Cody +> Sent: Wednesday, January 07, 2015 9:11 PM +> To: Lokesha, Amulya +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > Public bug reported: +> > > +> > > We are trying to convert a VMDK image to VHDX image for deploy to +> > > HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > converting the image using both 'fixed' as well as 'dynamic' +> > > format. We found that both the disks occupy the same size of 50GB. +> > > When the same is done with VHD image, we found that the dynamic +> > > disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > > +> > > Why is that the VHDX generates large sized images for both the +> > > formats? +> > > +> > > The following commands were used to convert the vmdk image to VHDX +> > > format +> > +> > Jeff, did you fix this recently in commit +> > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > +> > Stefan +> +> +> Yes, although there has been a report that there are issues in the +> resulting vhdx image in a MS server, after this patch. I am going to +> test and fix (if confirmed) once my MSDN subscription is renewed (in +> process now, I expect it anytime). +> +> Jeff +> +> -- +> +> Hi Jeff, +> +> Could you please give us a possible timeline of when fix will be +> available. Our customers are waiting on this as we are blocked with +> the image creation. +> +> Thanks, Amulya + +Hi Amulya, + +I have my MSDN stuff sorted out now, so give me a day or two get my test machine up and running & testing. + +-Jeff + + +Hi Jeff, + +Any updates on this? Where you able to get it tested + + Thanks, +-Amulya + +> +> +> You received this bug notification because you are subscribed to the bug report. +> https://bugs.launchpad.net/bugs/1399191 +> +> Title: +> Large VHDX image size +> +> Status in QEMU: +> New +> +> Bug description: +> We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> +> Why is that the VHDX generates large sized images for both the +> formats? +> +> The following commands were used to convert the vmdk image to VHDX +> format +> +> 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> Test-fixed.vhdx +> +> qemu-img info Test-fixed.vhdx +> image: Test-fixed.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> +> 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +> Test.vmdk Test-dynamic.vhdx +> +> qemu-img info Test-dynamic.vhdx +> image: Test-dynamic.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> We tried this with the following version of qemu +> 1. qemu-2.0.0 +> 2. qemu-2.1.2 +> 3. qemu-2.2.0-rc4 +> +> +> Please let us know how to create compact VHDX images using qemu-img. +> Thank you +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + +On Mon, Jan 19, 2015 at 03:19:05PM +0000, Lokesha, Amulya wrote: +> +> +> -----Original Message----- +> From: Jeff Cody [mailto:<email address hidden>] +> Sent: Tuesday, January 13, 2015 9:18 AM +> To: Lokesha, Amulya +> Cc: Bug 1399191; Geoffroy, Daniel +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> > Please find comments inline +> > +> > -----Original Message----- +> > From: <email address hidden> [mailto:<email address hidden>] On Behalf +> > Of Jeff Cody +> > Sent: Wednesday, January 07, 2015 9:11 PM +> > To: Lokesha, Amulya +> > Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> > +> > On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > > Public bug reported: +> > > > +> > > > We are trying to convert a VMDK image to VHDX image for deploy to +> > > > HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > > converting the image using both 'fixed' as well as 'dynamic' +> > > > format. We found that both the disks occupy the same size of 50GB. +> > > > When the same is done with VHD image, we found that the dynamic +> > > > disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > > > +> > > > Why is that the VHDX generates large sized images for both the +> > > > formats? +> > > > +> > > > The following commands were used to convert the vmdk image to VHDX +> > > > format +> > > +> > > Jeff, did you fix this recently in commit +> > > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > > +> > > Stefan +> > +> > +> > Yes, although there has been a report that there are issues in the +> > resulting vhdx image in a MS server, after this patch. I am going to +> > test and fix (if confirmed) once my MSDN subscription is renewed (in +> > process now, I expect it anytime). +> > +> > Jeff +> > +> > -- +> > +> > Hi Jeff, +> > +> > Could you please give us a possible timeline of when fix will be +> > available. Our customers are waiting on this as we are blocked with +> > the image creation. +> > +> > Thanks, Amulya +> +> Hi Amulya, +> +> I have my MSDN stuff sorted out now, so give me a day or two get my test machine up and running & testing. +> +> -Jeff +> +> +> Hi Jeff, +> +> Any updates on this? Where you able to get it tested +> +> Thanks, +> -Amulya +> + +Yes, I have sent a patch that I believe fixes the issue (I cc'ed you +on the patch). If you wouldn't mind testing, and verifying that it +fixes your particular issue, that would be great. I tested on Windows +Server 2012 w/Hyper-V, and I was able to verify the original problem +and the fix. + +On what the issue was: + +The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the +block state field is 'reserved' for blocks in the state +PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file +offset value for that block into the field, and just ignored it during +reads. + +If we force the FileOffsetMB field to be zero, then Hyper-V is able to +read the images. Furthermore, inspecting images converted by +Hyper-V shows that Hyper-V writes '0' for the FileOffsetMB +field in BAT entries that are in the PAYLOAD_BLOCK_ZERO state. + +The patch I sent mimics that behavior, and forces any BAT writes of +PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. + +> > +> > +> > You received this bug notification because you are subscribed to the bug report. +> > https://bugs.launchpad.net/bugs/1399191 +> > +> > Title: +> > Large VHDX image size +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the +> > formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> > +> > 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> > Test-fixed.vhdx +> > +> > qemu-img info Test-fixed.vhdx +> > image: Test-fixed.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > +> > 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +> > Test.vmdk Test-dynamic.vhdx +> > +> > qemu-img info Test-dynamic.vhdx +> > image: Test-dynamic.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > We tried this with the following version of qemu +> > 1. qemu-2.0.0 +> > 2. qemu-2.1.2 +> > 3. qemu-2.2.0-rc4 +> > +> > +> > Please let us know how to create compact VHDX images using qemu-img. +> > Thank you +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + + + +-----Original Message----- +From: Jeff Cody [mailto:<email address hidden>] +Sent: Wednesday, January 21, 2015 2:41 AM +To: Lokesha, Amulya +Cc: Bug 1399191; Geoffroy, Daniel +Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size + +On Mon, Jan 19, 2015 at 03:19:05PM +0000, Lokesha, Amulya wrote: +> +> +> -----Original Message----- +> From: Jeff Cody [mailto:<email address hidden>] +> Sent: Tuesday, January 13, 2015 9:18 AM +> To: Lokesha, Amulya +> Cc: Bug 1399191; Geoffroy, Daniel +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> > Please find comments inline +> > +> > -----Original Message----- +> > From: <email address hidden><mailto:<email address hidden>> [mailto:<email address hidden>] On Behalf +> > Of Jeff Cody +> > Sent: Wednesday, January 07, 2015 9:11 PM +> > To: Lokesha, Amulya +> > Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> > +> > On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > > Public bug reported: +> > > > +> > > > We are trying to convert a VMDK image to VHDX image for deploy +> > > > to HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > > converting the image using both 'fixed' as well as 'dynamic' +> > > > format. We found that both the disks occupy the same size of 50GB. +> > > > When the same is done with VHD image, we found that the dynamic +> > > > disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > > > +> > > > Why is that the VHDX generates large sized images for both the +> > > > formats? +> > > > +> > > > The following commands were used to convert the vmdk image to +> > > > VHDX format +> > > +> > > Jeff, did you fix this recently in commit +> > > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > > +> > > Stefan +> > +> > +> > Yes, although there has been a report that there are issues in the +> > resulting vhdx image in a MS server, after this patch. I am going +> > to test and fix (if confirmed) once my MSDN subscription is renewed +> > (in process now, I expect it anytime). +> > +> > Jeff +> > +> > -- +> > +> > Hi Jeff, +> > +> > Could you please give us a possible timeline of when fix will be +> > available. Our customers are waiting on this as we are blocked with +> > the image creation. +> > +> > Thanks, Amulya +> +> Hi Amulya, +> +> I have my MSDN stuff sorted out now, so give me a day or two get my test machine up and running & testing. +> +> -Jeff +> +> +> Hi Jeff, +> +> Any updates on this? Where you able to get it tested +> +> Thanks, +> -Amulya +> + +Yes, I have sent a patch that I believe fixes the issue (I cc'ed you on the patch). If you wouldn't mind testing, and verifying that it fixes your particular issue, that would be great. I tested on Windows Server 2012 w/Hyper-V, and I was able to verify the original problem and the fix. + +On what the issue was: + +The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the block state field is 'reserved' for blocks in the state PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file offset value for that block into the field, and just ignored it during reads. + +If we force the FileOffsetMB field to be zero, then Hyper-V is able to read the images. Furthermore, inspecting images converted by Hyper-V shows that Hyper-V writes '0' for the FileOffsetMB field in BAT entries that are in the PAYLOAD_BLOCK_ZERO state. + +The patch I sent mimics that behavior, and forces any BAT writes of PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. + + +Hi Jeff, + +Thanks a lot for the fix. We tested the VHDX creation with the new patch fix and were able to get it deployed successfully into our Windows HyperV Server 2012. + +However we have one more issue and were hoping if we could get any help. We have a vmdk image (size 13MB) with a 500 GB data disk size. After conversion of vmdk image to vhdx format, the image size is 126 GB. + +# qemu-img info Test.vmdk +image: Test.vmdk +file format: vmdk +virtual size: 500G (536870912000 bytes) +disk size: 13M +cluster_size: 65536 +Format specific information: + cid: 4124953209 + parent cid: 4294967295 + create type: streamOptimized + extents: + [0]: + compressed: true + virtual size: 536870912000 + filename: Test.vmdk + cluster size: 65536 + format: + +qemu conversion to vhdx done as below +# qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test.vhdx + (100.00/100%) + +# ls -ltrh +total 69M +-rw-r--r-- 1 root root 13M Jan 21 21:42 Test.vmdk +-rw-r--r-- 1 root root 126G Jan 22 05:03 Test.vhdx + +# qemu-img info Test.vhdx +image: Test.vhdx +file format: vhdx +virtual size: 500G (536870912000 bytes) +disk size: 56M +cluster_size: 33554432 + + +When we tried to copy this to the SCVMM manager server (Windows OS) it failed due to disk limitation. Windows does think it is a 126 GB file. Can anything be done to fix this issue? + +Thanks, +Amulya +> > +> > +> > You received this bug notification because you are subscribed to the bug report. +> > https://bugs.launchpad.net/bugs/1399191 +> > +> > Title: +> > Large VHDX image size +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the +> > formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> > +> > 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> > Test-fixed.vhdx +> > +> > qemu-img info Test-fixed.vhdx +> > image: Test-fixed.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > +> > 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +> > Test.vmdk Test-dynamic.vhdx +> > +> > qemu-img info Test-dynamic.vhdx +> > image: Test-dynamic.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > We tried this with the following version of qemu +> > 1. qemu-2.0.0 +> > 2. qemu-2.1.2 +> > 3. qemu-2.2.0-rc4 +> > +> > +> > Please let us know how to create compact VHDX images using qemu-img. +> > Thank you +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + + +On Thu, Jan 22, 2015 at 05:20:20AM +0000, Lokesha, Amulya wrote: +> +> + +[...] + +> +>> Yes, I have sent a patch that I believe fixes the issue (I cc'ed you on +>> the patch). If you wouldn't mind testing, and verifying that it fixes +>> your particular issue, that would be great. I tested on Windows Server +>> 2012 w/Hyper-V, and I was able to verify the original problem and the fix. +>> +>> On what the issue was: +>> +>> The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the +>> block state field is 'reserved' for blocks in the state +>> PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file offset +>> value for that block into the field, and just ignored it during reads. +>> +>> If we force the FileOffsetMB field to be zero, then Hyper-V is able to +>> read the images. Furthermore, inspecting images converted by Hyper-V +>> shows that Hyper-V writes '0' for the FileOffsetMB field in BAT entries +>> that are in the PAYLOAD_BLOCK_ZERO state. +>> +>> The patch I sent mimics that behavior, and forces any BAT writes of +>> PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. +> +> +> Hi Jeff, +> +> Thanks a lot for the fix. We tested the VHDX creation with the new patch +> fix and were able to get it deployed successfully into our Windows HyperV +> Server 2012. +> + +You're welcome! + +> However we have one more issue and were hoping if we could get any help. +> We have a vmdk image (size 13MB) with a 500 GB data disk size. After +> conversion of vmdk image to vhdx format, the image size is 126 GB. +> +> # qemu-img info Test.vmdk +> image: Test.vmdk +> file format: vmdk +> virtual size: 500G (536870912000 bytes) +> disk size: 13M +> cluster_size: 65536 +> Format specific information: +> cid: 4124953209 +> parent cid: 4294967295 +> create type: streamOptimized +> extents: +> [0]: +> compressed: true +> virtual size: 536870912000 +> filename: Test.vmdk +> cluster size: 65536 +> format: +> +> qemu conversion to vhdx done as below +> # qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk +> Test.vhdx +> (100.00/100%) +> +> # ls -ltrh +> total 69M +> -rw-r--r-- 1 root root 13M Jan 21 21:42 Test.vmdk +> -rw-r--r-- 1 root root 126G Jan 22 05:03 Test.vhdx +> +> # qemu-img info Test.vhdx +> image: Test.vhdx +> file format: vhdx +> virtual size: 500G (536870912000 bytes) +> disk size: 56M +> cluster_size: 33554432 +> +> +> When we tried to copy this to the SCVMM manager server (Windows OS) it +> failed due to disk limitation. Windows does think it is a 126 GB file. Can +> anything be done to fix this issue? +> +> Thanks, +> Amulya + +It sounds like a 126G sparse image was created (reported size 126G, on +disk size 55M), and QEMU still recognizes it as a 500G image (file +size sounds large, but nothing indicates yet the vhdx image isn't +valid, at least). + +I am not sure what your disk limitation limit was under Windows, can +you elaborate? + +I tried to reproduce it here, and could not: + +# ./qemu-img create -f vmdk test-500G.vmdk 500G + +# ./qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx test-500G.vmdk test-500G.vhdx + +# ls -lhs test-500G* +1.3M -rw-r--r--. 1 jcody jcody 8.0M Jan 22 10:25 test-500G.vhdx +136K -rw-r--r--. 1 jcody jcody 63M Jan 22 10:25 test-500G.vmdk + +I was also able to inspect test.vhdx on Windows Server 2012, using +Hyper-V Manager, and it reported that it was a vhdx dynamic disk, with +a maximum size of 500G. + +Can you place your source vmdk image someplace for me to download and +test with, if it does not contain sensitive data? You can send me the +link offlist, if you like. + +Thanks, +Jeff + +> > > +> > > +> > > You received this bug notification because you are subscribed to the +> bug report. +> > > [5]https://bugs.launchpad.net/bugs/1399191 +> > > + + +[...] + + +On Thu, Jan 22, 2015 at 04:24:45PM +0000, Lokesha, Amulya wrote: +> +> -----Original Message----- +> From: Jeff Cody [mailto:<email address hidden>] +> Sent: Thursday, January 22, 2015 9:33 PM +> To: Lokesha, Amulya +> Cc: Bug 1399191; Geoffroy, Daniel +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Thu, Jan 22, 2015 at 05:20:20AM +0000, Lokesha, Amulya wrote: +> > +> > +> +> [...] +> +>>> +>>>> Yes, I have sent a patch that I believe fixes the issue (I cc'ed you on +>>>> the patch). If you wouldn't mind testing, and verifying that it fixes +>>>> your particular issue, that would be great. I tested on Windows Server +>>>> 2012 w/Hyper-V, and I was able to verify the original problem and the fix. +>>>> +>>>> On what the issue was: +>>>> +>>>> The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the +>>>> block state field is 'reserved' for blocks in the state +>>>> PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file offset +>>>> value for that block into the field, and just ignored it during reads. +>>>> +>>>> If we force the FileOffsetMB field to be zero, then Hyper-V is able to +>>>> read the images. Furthermore, inspecting images converted by Hyper-V +>>>> shows that Hyper-V writes '0' for the FileOffsetMB field in BAT entries +>>>> that are in the PAYLOAD_BLOCK_ZERO state. +>>>> +>>>> The patch I sent mimics that behavior, and forces any BAT writes of +>>>> PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. +>>> +>>> +>>> Hi Jeff, +>>> +>>> Thanks a lot for the fix. We tested the VHDX creation with the new patch +>>> fix and were able to get it deployed successfully into our Windows HyperV +>>> Server 2012. +>>> +>> +>>You're welcome! +>> +>>> However we have one more issue and were hoping if we could get any help. +>>> We have a vmdk image (size 13MB) with a 500 GB data disk size. After +>>> conversion of vmdk image to vhdx format, the image size is 126 GB. +>>> +>>> # qemu-img info Test.vmdk +>>> image: Test.vmdk +>>> file format: vmdk +>>> virtual size: 500G (536870912000 bytes) +>>> disk size: 13M +>>> cluster_size: 65536 +>>> Format specific information: +>>> cid: 4124953209 +>>> parent cid: 4294967295 +>>> create type: streamOptimized +>>> extents: +>>> [0]: +>>> compressed: true +>>> virtual size: 536870912000 +>>> filename: Test.vmdk +>>> cluster size: 65536 +>>> format: +>>> +>>> qemu conversion to vhdx done as below +>>> # qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk +>>> Test.vhdx +>>> (100.00/100%) +>>> +>>> # ls -ltrh +>>> total 69M +>>> -rw-r--r-- 1 root root 13M Jan 21 21:42 Test.vmdk +>>> -rw-r--r-- 1 root root 126G Jan 22 05:03 Test.vhdx +>>> +>>> # qemu-img info Test.vhdx +>>> image: Test.vhdx +>>> file format: vhdx +>>> virtual size: 500G (536870912000 bytes) +>>> disk size: 56M +>>> cluster_size: 33554432 +>>> +>>> +>>> When we tried to copy this to the SCVMM manager server (Windows OS) it +>>> failed due to disk limitation. Windows does think it is a 126 GB file. Can +>>> anything be done to fix this issue? +>>> +>>> Thanks, +>>> Amulya +>> +>> It sounds like a 126G sparse image was created (reported size 126G, +>> on disk size 55M), and QEMU still recognizes it as a 500G image +>> (file size sounds large, but nothing indicates yet the vhdx image +>> isn't valid, at least). +>> +>> +>> I tried to reproduce it here, and could not: +>> +>> # ./qemu-img create -f vmdk test-500G.vmdk 500G +>> +>> # ./qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +>> test-500G.vmdk test-500G.vhdx +>> +>> # ls -lhs test-500G* +>> 1.3M -rw-r--r--. 1 jcody jcody 8.0M Jan 22 10:25 test-500G.vhdx +>> 136K -rw-r--r--. 1 jcody jcody 63M Jan 22 10:25 test-500G.vmdk +>> +>> I was also able to inspect test.vhdx on Windows Server 2012, using +>> Hyper-V Manager, and it reported that it was a vhdx dynamic disk, +>> with a maximum size of 500G. +>> +>> Can you place your source vmdk image someplace for me to download +>> and test with, if it does not contain sensitive data? You can send +>> me the link offlist, if you like. +>> +> +> Hi Jeff, +> +> The disk limitation which I mentioned above was just about the free +> space available on Windows hyperV Server. I am sending the sample +> Test.vmdk attached in zip format which we used for converting to +> vhdx format. Please let me know if you are able to download this zip +> file. +> +> Thanks, Amulya +> +> + +Hi Amulya, + +(I added the bug tracker back on the cc list) + +I was able to download the VMDK image fine to test. What is going +on is due to the nature of the VHDX image format, due to its +relatively large block size (1MB min, 256 MB max). + +Brief background: + +In the VHDX image format, data is broken up into blocks. Those blocks +may take various states, such as a 'ZERO' state, and a 'PRESENT' +state. + +When an entire block is zeroes, the state stays in the 'ZERO' state, +which is now the default state for new VHDX dynamic image files. +There is no data written to disk for these zeros, so the file size +stays small. + +However, if we write even 1 byte to a block that is the ZERO state, it +is now in the 'PRESENT' state, and that block data must be written to +disk (complete with the surrounding zeroes in that block). + +Block sizes for VHDX images range from 1MB - 256MB. The larger the +block size, the larger the image may be on disk for partially filled +blocks. + +The qemu vhdx driver does take advantage of underlying file system +sparseness, however, and just extends the file out and only writes the +requested sectors on a write. + + +What is going on in your VMDK image: + +You VMDK image as a lot of (repetitive) data spread out far enough +apart that it hits a lot of different blocks [1]. If you run hexdump on +the resulting vhdx image, this will be apparent (hexdump will elide +excessively duplicate data, so the output is manageable). + +The resulting image with the default block size then becomes ~126G, +but as it is quite sparse, the on disk usage is only 41M. If you play +with the block size parameter during conversion, you can get file size +down to around 4G (with a block_size of 1MB). + +I am not sure the best way to copy a sparse file over to Windows +2012 Server, but it would probably be nice to preserve any sparseness +if possible. + +I think we can close the BZ, as it seems the posted patch solves +the original issue. + + +[1] Example of data from the converted VHDX image: + +7f000000 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f000040 0003 0000 0000 0000 0000 0000 0000 0000 +7f000050 0000 0000 0000 0000 0000 0000 0000 0000 +* +7f001400 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f002000 0000 0000 0000 0000 0000 0000 0000 0000 +* +7f100000 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f100040 0003 0000 0000 0000 0000 0000 0000 0000 +7f100050 0000 0000 0000 0000 0000 0000 0000 0000 +* +7f101400 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f102000 0000 0000 0000 0000 0000 0000 0000 0000 + + +The default block size for a 500G vhdx image created by QEMU is 32M. +In the above, you can see that most of the data is 0, but still within +one block-sized chunk. + +(I am assuming that the data was converted correctly, of course). + +When I tested with a qcow2 output format, using a 1MB cluster size in +qcow2, I get roughly similar results as when using a block size of 1M +with vhdx (Test.qcow2 and Test.vhdx were then both ~4G). + +-Jeff + +>>> > > +>>> > > +>>> > > You received this bug notification because you are subscribed to the +>>> bug report. +>>> > > https://bugs.launchpad.net/bugs/1399191 +>>> > > +>> +>> +>>[...] + + + + +We have encountered the same problem. +We have a 1.4 GB size vmdk image and after converting it to vhdx, its size is 62GB. But qemu-img info show the size is 2.9 G. +=========== +$ qemu-img info dd_test.vmdk +image: dd_test.vmdk +file format: vmdk +virtual size: 250G (268435456000 bytes) +disk size: 1.4G +$ qemu-img convert -p -f vmdk dd_test.vmdk -O vhdx t.vhdx + (98.02/100%) + +$ qemu-img info t.vhdx +image: t.vhdx +file format: vhdx +virtual size: 250G (268435456000 bytes) +disk size: 2.9G +$ ls -ltrh t.vhdx +-rw-r--r-- 1 wangj85 wangj85 62G Dec 28 2015 t.vhdx + + + + +qemu-img version is 1.5.3. I also use newer version to do the conversion, it has the same result. + +If your image contains an ext4 partition it may be worth viewing the advice MS gives about Dynamic VHDX blocksizes: https://technet.microsoft.com/en-GB/library/dn720239.aspx . + +Hi Jan, + +ls -l returns the length of the file; qemu-img info prints the size of the file (just like du does). Those are not necessarily the same, as you can see. On modern filesystems, files can have holes in them which do contribute to the file length, but which do not use any space on disk and thus do not contribute to file size. + +Besides using qemu-img, you can obtain the actual disk usage (the file size) by using du or ls --size (-s for short). + +Max + +Sorry. +Please ignore above change. I just find that I change the status of this bug +https://bugs.launchpad.net/qemu/+bug/1490611 +I really don't know I have privilege to modify that. +Sorry again. + +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/105/KVM/1405385 b/results/classifier/105/KVM/1405385 new file mode 100644 index 00000000..440e9110 --- /dev/null +++ b/results/classifier/105/KVM/1405385 @@ -0,0 +1,278 @@ +KVM: 0.826 +vnc: 0.765 +other: 0.763 +mistranslation: 0.663 +device: 0.635 +instruction: 0.612 +network: 0.600 +graphic: 0.598 +boot: 0.577 +socket: 0.544 +semantic: 0.536 +assembly: 0.500 + +QEMU crashes when virtio network cards are used together with e1000 network cards + +QEMU version: QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard +QEMU GIT version: ab0302ee764fd702465aef6d88612cdff4302809 +Configure flags: ./configure --enable-kvm --prefix=/opt/qemu-devel +Linux version: Ubuntu 14.04.1 LTS +Kernel version: 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux + +Problem: + + QEMU crashes when using one (or more) virtio network cards together with one (or more) e1000 (and possibly others) network cards when those cards are bound to a linux bridge. When the cards are *not* bound to a bridge QEMU does not crash. + +Bridge configuration: + + iface bridge0 inet dhcp + bridge_ports eth1 + bridge_stp off + bridge_fd 0 + +Start-up command (including binding the network cards to the bridge + strace logging): + +./qemu-system-x86_64 -daemonize -smp 1 -m 128 -vnc 0.0.0.0:0 \ +-netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on \ +-device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA \ +-netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 \ +-device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB; \ +brctl addif bridge0 net_1_1; \ +brctl addif bridge0 net_1_2; \ +ifconfig net_1_1 0.0.0.0 up; \ +ifconfig net_1_2 0.0.0.0 up; \ +sleep 2; \ +strace -p `ps x |grep qemu-system-x86_64 |grep -v grep|awk '{print $1}'` -o /tmp/qemu-devel-trace.txt + +Kernel log: + +Dec 24 11:12:08 bramws kernel: [12466.885581] device net_1_1 entered promiscuous mode +Dec 24 11:12:08 bramws kernel: [12466.886238] device net_1_2 entered promiscuous mode +Dec 24 11:12:08 bramws kernel: [12466.887084] bridge0: port 2(net_1_1) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.887089] bridge0: port 2(net_1_1) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.888940] bridge0: port 3(net_1_2) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.888947] bridge0: port 3(net_1_2) entered forwarding state +Dec 24 11:12:29 bramws kernel: [12488.026376] bridge0: port 2(net_1_1) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.026820] device net_1_1 left promiscuous mode +Dec 24 11:12:29 bramws kernel: [12488.026832] bridge0: port 2(net_1_1) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.049636] bridge0: port 3(net_1_2) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.050058] device net_1_2 left promiscuous mode +Dec 24 11:12:29 bramws kernel: [12488.050074] bridge0: port 3(net_1_2) entered disabled state + +Strace log: (full log attached) + +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 28646613}, NULL, 8) = 0 (Timeout) +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 10899760}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 10895457}) +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +read(5, "\1\0\0\0\0\0\0\0", 512) = 8 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +read(6, "\2\0\0\0\0\0\0\0", 16) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +read(6, 0x7fff697320e0, 16) = -1 EAGAIN (Resource temporarily unavailable) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 9570429}, NULL, 8) = 0 (Timeout) +futex(0x7f011c8ef094, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 224) = 1 +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 54463396}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 54459649}) +tgkill(7779, 7784, SIGUSR1) = 0 +futex(0x7f011aaa0824, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 1650) = 1 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +read(5, "\2\0\0\0\0\0\0\0", 512) = 8 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +read(6, "\2\0\0\0\0\0\0\0", 16) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +read(6, 0x7fff697320e0, 16) = -1 EAGAIN (Resource temporarily unavailable) +futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 53843633}, NULL, 8 <unfinished ...> ++++ killed by SIGABRT +++ + + + +What does qemu say when aborting? + +Hm. I guess it says nothing, as else some write(2) should be seen by strace. So it is like abort() not assert(). And we have about 800 abort() calls in the code. Oh well. + +Indeed, it does not say anything, it simply crashes. Besides the strace log I created I can't find any other usefull information in other logfiles. + +a backtrace from a coredump or gdb would be better; it'll tell us the line the abort is on and the state at that point. +Run it under gdb and do + +bt full + +and paste the result. + +I can't reproduce this, no matter how hard I try. Tried 4 virtio devices and 4 e1000 devices (8 network devices in total). Tried 2.1 and 2.2 and current git. It all Just Works (tm). What I'm doing wrong? :) + +I think your just not trying hard enough ;-) + +I have reproduced this on four different (bare metal) machines. I used the default ubuntu QEMU (2.0.0) and the latest GIT version. All machines where running ubuntu 14.04. I also tried to reproduce it on a virtualbox VM and I could only get it to crash when I put the network card of my virtual machine (the virtualbox one) in promiscuous modus. If I would set promiscuous modus to "deny all" in virtual box QEMU would not crash. + +I will do the gdb debug trace when I get back at work, I don't have a suitable system available at home to test this with. + +I have a hard time getting a full backtrace. I recompiled qemu with --enable-debug. Running QEMU with -s -S and then using GDB with debug using: attach remote localhost:1234 works but when QEMU has crashed the command "bt full" always gives back: + +(gdb) bt full +No stack. + +I then ran QEMU directly from GDB using: run -nographic -smp 1 -m 128 -vnc 0.0.0.0:0 -netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on -device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA -netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 -device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB + +I have to press a key continuously to get QEMU "running" (otherwise it halts). Right before QEMU crashes I get this error in gdb: + +Program received signal SIGUSR1, User defined signal 1. +spin_lock (lock=0x5a4f072640e15f00) at /home/bram/git/qemu/include/exec/spinlock.h:42 +42 { +(gdb) +Continuing. +qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000074f0a5f9 + +EAX=00000000 EBX=0001939c ECX=00009cf3 EDX=00001c79 +ESI=f81ac248 EDI=0009bd70 EBP=0009bd20 ESP=0009bd14 +EIP=6d016c49 EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 07ef39b0 ffffffff 00cf9f00 DPL=0 CS32 [CRA] +SS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 0009cf40 00000037 +IDT= 07f8df10 00006deb +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=000193bc CCD=ffffffe0 CCO=SUBL +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 + +Program received signal SIGABRT, Aborted. +0x00007ffff2797bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. +(gdb) +Continuing. +[Thread 0x7fffdadff700 (LWP 27991) exited] +[Thread 0x7ffff7fa8980 (LWP 27930) exited] + +Program terminated with signal SIGABRT, Aborted. + +If I run bt full right after that I get the exact same "No stack." error. I then created a core dump and ran the bt full on that, giving me this output: + +#0 0x00007f038ec86bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 + resultvar = 0 + pid = 29457 + selftid = 29462 +#1 0x00007f038ec89fc8 in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x4c425553, sa_sigaction = 0x4c425553}, sa_mask = {__val = {139653355451349, 893353197568, 139653355450960, 139653355450970, + 15179618306775321344, 1, 139653029951232, 0, 0, 139653029951936, 139653029951232, 139653029947664, 139653353918150, 1688849860263936, 139653257249376, + 139653260837312}}, sa_flags = -1760754560, sa_restorer = 0x7f039708a7e0} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007f039459377f in cpu_abort (cpu=0x7f03970d0480, fmt=0x7f03949f2830 "Trying to execute code outside RAM or ROM at 0x%016lx\n") at /home/bram/git/qemu/exec.c:805 + ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7f03813dea30, reg_save_area = 0x7f03813de970}} + ap2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f03813dea30, reg_save_area = 0x7f03813de970}} +#3 0x00007f03945f4d20 in get_page_addr_code (env1=0x7f03970d86d0, addr=1961928185) at /home/bram/git/qemu/cputlb.c:357 + cc = 0x7f039708a7e0 + mmu_idx = 2 + page_index = 10 + pd = 0 + p = 0x7ef5000 + mr = 0x7f0394e79620 <io_mem_unassigned> + cpu = 0x7f03970d0480 + __func__ = "get_page_addr_code" +#4 0x00007f039459c38e in tb_find_slow (env=0x7f03970d86d0, pc=1961928185, cs_base=133118384, flags=244) at /home/bram/git/qemu/cpu-exec.c:243 + cpu = 0x7f03970d0480 + tb = 0x4fb813deb00 + ptb1 = 0x7f0394a03680 + h = 32515 + phys_pc = 139653395842176 + phys_page1 = 139653029948228 + virt_page2 = 139653029948232 +#5 0x00007f039459c63c in tb_find_fast (env=0x7f03970d86d0) at /home/bram/git/qemu/cpu-exec.c:300 + cpu = 0x7f03970d0480 + tb = 0x0 + cs_base = 133118384 + pc = 1961928185 + flags = 244 +#6 0x00007f039459cade in cpu_x86_exec (env=0x7f03970d86d0) at /home/bram/git/qemu/cpu-exec.c:456 + cpu = 0x7f03970d0480 + cc = 0x7f039708a7e0 + __func__ = "cpu_x86_exec" + x86_cpu = 0x7f03970d0480 + ret = 65536 + interrupt_request = 2 + tb = 0x7f038166b6d8 + tc_ptr = 0x7f0383576ad0 "A\213n\364\205\355\017\205\245" + next_tb = 0 + sc = {diff_clk = 139653029948416, last_cpu_icount = 139653351987455, realtime_clock = 139653029948448} + have_tb_lock = true +#7 0x00007f03945ca913 in tcg_cpu_exec (env=0x7f03970d86d0) at /home/bram/git/qemu/cpus.c:1363 + cpu = 0x7f03970d0480 + ret = 32515 +#8 0x00007f03945caa28 in tcg_exec_all () at /home/bram/git/qemu/cpus.c:1396 + cpu = 0x7f03970d0480 + env = 0x7f03970d86d0 + r = 32515 +#9 0x00007f03945c9d47 in qemu_tcg_cpu_thread_fn (arg=0x7f03970d0480) at /home/bram/git/qemu/cpus.c:1042 + cpu = 0x0 +#10 0x00007f038f01e182 in start_thread (arg=0x7f03813df700) at pthread_create.c:312 + __res = <optimized out> + pd = 0x7f03813df700 + now = <optimized out> + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139653029951232, 5823000673722110008, 0, 0, 139653029951936, 139653029951232, -5852297728485158856, -5852310887850110920}, + mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> + pagesize_m1 = <optimized out> + sp = <optimized out> + freesize = <optimized out> + __PRETTY_FUNCTION__ = "start_thread" +#11 0x00007f038ed4aefd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +No locals. + + +Im not sure if this is all the information needed? I attached the core dump. + +On 29 December 2014 at 08:29, Bram Klein Gunnewiek +<email address hidden> wrote: +> Right before QEMU crashes I get this error in gdb: +> +> Program received signal SIGUSR1, User defined signal 1. + +SIGUSR1 is used internally by QEMU. You can tell gdb not to +bother you about it: + + handle SIGUSR1 pass noprint nostop + +before running. + +-- PMM + + +I'm not sure if there is more information required from my side? I can still reproduce this and have no clue where to look for more information. + +On Fri, Jan 09, 2015 at 07:30:05AM -0000, Bram Klein Gunnewiek wrote: +> I'm not sure if there is more information required from my side? I can +> still reproduce this and have no clue where to look for more +> information. + +I cannot reproduce a crash from your command-line with qemu.git/master +(3e5f6234b4f45a11b7c357dde2d6da36641bc6f6). + + +Looking through old bug tickets... Bram, 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/105/KVM/1408152 b/results/classifier/105/KVM/1408152 new file mode 100644 index 00000000..70da0608 --- /dev/null +++ b/results/classifier/105/KVM/1408152 @@ -0,0 +1,29 @@ +KVM: 0.894 +boot: 0.806 +instruction: 0.773 +network: 0.699 +device: 0.675 +socket: 0.579 +graphic: 0.521 +mistranslation: 0.449 +semantic: 0.430 +vnc: 0.365 +other: 0.359 +assembly: 0.172 + +latest qemu git doesn't load + +commit ab0302ee764fd702465aef6d88612cdff4302809This is with + +qemu-system-x86_64: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. +/home/njh/bin/kfreebsd-amd64: line 7: 32549 Aborted (core dumped) qemu-system-x86_64 -drive file=kfreebsd-amd64,index=0,media=disk,cache=writeback,aio=native -drive file=/dev/sr0,index=1,media=cdrom -boot c -redir tcp:2232::22 -m 1024 -machine accel=kvm,kernel_irqchip=on -cpu host -net user,hostname=qemu.bandsman.co.uk -net nic,model=e1000 -k en-us + +Seems to be failing to parse kernel_irqchip=on correctly. + +This issue seems to be similar to 1406706 and 1407454. Looks Marcel is working on a fix, and he also posted something to first address USB stuff, + +https://<email address hidden>/msg272607.html + +Hi; we fixed this with commit 446f16a6906e9d0 in March 2015, so I'm going to mark this as fixed. + + diff --git a/results/classifier/105/KVM/1435359 b/results/classifier/105/KVM/1435359 new file mode 100644 index 00000000..ec450c51 --- /dev/null +++ b/results/classifier/105/KVM/1435359 @@ -0,0 +1,61 @@ +KVM: 0.602 +other: 0.547 +device: 0.513 +instruction: 0.512 +boot: 0.472 +mistranslation: 0.464 +network: 0.449 +socket: 0.426 +graphic: 0.421 +vnc: 0.420 +semantic: 0.379 +assembly: 0.373 + +Booting kernel 3.19.2 fails most of the time + +Host system: openSuSE 13.2 + kernel 4.0.0-rc4 + qemu 2.2.1. + +When I try to boot a virtual machine with Ubuntu 14.10 and kernel 3.13.0 every boot succeeds. However, with kernel 3.19.2 booting fails most of the time. The following appears in /var/log/libvirt/qemu/ubuntu-vm.log when I try to boot that VM with kernel 3.19.2: + +2015-03-23 02:44:18.801+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name ubuntu-vm -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Haswell -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 395110dc-9fbe-4542-8fce-4ef958f24b2c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ubuntu-vm.monitor,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 -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -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=0x4 -drive file=/var/lib/libvirt/images/ubuntusaucy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/libvirt/images/ubuntu-14.04-mini.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:5e:71:5e,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x9 -msg timestamp=on +main_channel_link: add main channel client +main_channel_handle_parsed: net test: latency 0.229000 ms, bitrate 28444444444 bps (27126.736111 Mbps) +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +((null):30728): SpiceWorker-ERROR **: red_worker.c:8337:red_marshall_qxl_drawable: invalid type +KVM: injection failed, MSI lost (Input/output error) +qemu-system-x86_64: /home/bart/software/qemu-2.2.1/hw/net/vhost_net.c:264: vhost_net_stop_one: Assertion `r >= 0' failed. +2015-03-23 02:44:44.952+0000: shutting down + +That message is similar to the message reported by the older qemu version provided by openSuse (qemu 2.1.0 + qemu-kvm 2.1.0): + +2015-03-21 13:51:00.724+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name ubuntu-vm -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Haswell -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 395110dc-9fbe-4542-8fce-4ef958f24b2c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ubuntu-vm.monitor,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 -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -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=0x6 -drive file=/var/lib/libvirt/images/ubuntusaucy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/libvirt/images/ubuntu-14.04-mini.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id +=ide0-0-0,bootindex=2 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:5e:71:5e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1, +name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x9 -msg timestamp=on +char device redirected to /dev/pts/0 (label charserial0) +main_channel_link: add main channel client +main_channel_handle_parsed: net test: latency 0.233000 ms, bitrate 17964912280 bps (17132.675438 Mbps) +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +((null):5798): SpiceWorker-ERROR **: red_worker.c:8337:red_marshall_qxl_drawable: invalid type +red_channel_client_disconnect: 0x7f90397ec0c0 (channel 0x7f903812a090 type 5 id 0) +((null):8349): Spice-Warning **: red_channel.c:1661:red_channel_remove_client: channel type 5 id 0 - channel->thread_id (0x7f90362cba80) != pthread_self (0x7f9011fff700).If one of the threads is != io-thread && != vcpu-thread, this might be a BUG +snd_channel_put: sound channel freed +red_channel_client_disconnect: 0x7f903a04c4c0 (channel 0x7f903812a230 type 6 id 0) +((null):8349): Spice-Warning **: red_channel.c:1661:red_channel_remove_client: channel type 6 id 0 - channel->thread_id (0x7f90362cba80) != pthread_self (0x7f9011fff700).If one of the threads is != io-thread && != vcpu-thread, this might be a BUG +snd_channel_put: sound channel freed +KVM: injection failed, MSI lost (Input/output error) +qemu-system-x86_64: /home/abuild/rpmbuild/BUILD/qemu-2.1.0/hw/virtio/vhost.c:1003: vhost_virtqueue_mask: Assertion `r >= 0' failed. +2015-03-21 15:30:10.148+0000: shutting down + +The following patch might fix this (I have not yet tested this patch myself): https://lkml.org/lkml/2015/7/5/217 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I haven't seen this for a long time so please proceed with closing this ticket. + +Ok, thanks, so I'm closing this now. + diff --git a/results/classifier/105/KVM/1441443 b/results/classifier/105/KVM/1441443 new file mode 100644 index 00000000..c4da2eb1 --- /dev/null +++ b/results/classifier/105/KVM/1441443 @@ -0,0 +1,53 @@ +KVM: 0.988 +network: 0.963 +device: 0.936 +socket: 0.809 +mistranslation: 0.781 +other: 0.761 +instruction: 0.753 +graphic: 0.690 +vnc: 0.644 +semantic: 0.626 +boot: 0.563 +assembly: 0.441 + +Is there a way to create a 10G network interface for VMs in KVM2.0? + + + +We have installed & configured the KVM 2.0 (qemu-kvm 2.0.0+dfsg-2ubuntu1.10) on Ubuntu 14.04. The physical server is connected to 10G network, KVM is configured in Bridged mode But the issue is, when we create Network interface on VMs, we have only 1G device as an options for vmhosts. Is this the limit of the KVM or is there a way to create a 10G network interface for VMs? Available device models + +E1000 +Ne2k_pci +Pcnet +Rtl8139 +virtio + +Please find the network configuration details + +Source device : Host device vnet1 (Bridge ‘br0’) +Device model : virtio + +Network configuration in the host /etc/network/interfaces + +auto br0 +iface br0 inet static + address 10.221.x.10 + netmask 255.255.255.0 + network 10.221.x.0 + broadcast 10.221.x.255 + gateway 10.221.x.1 + # dns-* options are implemented by the resolvconf package, if installed + dns-nameservers X.X.X.X + dns-search XXX.NET + bridge_ports em1 + bridge_fd 0 + bridge_stp off + bridge_maxwait 0 + +Looking through old bug tickets ... have you already tried to use vhost-net? That should be one of the fastest ways of networking with QEMU as far as I know... + +Unless you are using SRIOV or DPDK which both need hardware support. If could support SRIOV, then using IOMMU+VFIO, and pass-through to VM, this will get a close number. Or DPDK, using a user-space driver + vhost-net, will also get a pretty good value. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1446726 b/results/classifier/105/KVM/1446726 new file mode 100644 index 00000000..c4a5c812 --- /dev/null +++ b/results/classifier/105/KVM/1446726 @@ -0,0 +1,52 @@ +KVM: 0.577 +other: 0.548 +instruction: 0.488 +mistranslation: 0.479 +device: 0.465 +socket: 0.460 +vnc: 0.459 +assembly: 0.452 +semantic: 0.445 +network: 0.443 +graphic: 0.434 +boot: 0.428 + +qemu stable 2.0 crashes during loadvm + +Qemu output: + +2015-03-06 01:06:54.255+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name instance-0000462a -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu Westmere,+erms,+smep,+3dnowprefetch,+rdtscp,+rdrand,+tsc-deadline,+movbe,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7c3f225c-df2a-4014-997b-3200fcfff43d -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.1.2,serial=474aef35-d474-8001-e411-6108001017ac,uuid=7c3f225c-df2a-4014-997b-3200fcfff43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000462a.monitor,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=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/mapper/258c232d7056e0047,if=none,id=drive-virtio-disk1,format=raw,serial=dedb9d8d-e727-4d09-bf89-52e870125303,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk.config,if=none,id=drive-virtio-disk25,format=raw,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk25,id=virtio-disk25 -chardev file,id=charserial0,path=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/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 127.0.0.1:0 -k ja -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming fd:23 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 +char device redirected to /dev/pts/3 (label charserial1) +qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/memory.c:1403: memory_region_del_eventfd: Assertion `i != mr->ioeventfd_nb' failed. +2015-03-06 01:09:02.585+0000: shutting down + + +Libvirt log: +2015-03-05 11:29:48.434+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:13:33.077+0000: 8397: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 00:13:40.981+0000: 8397: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:14:27.206+0000: 8396: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:14:40.160+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 00:20:45.414+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:26:21.849+0000: 8396: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/25, skipping +2015-03-06 00:26:24.764+0000: 8396: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:28:09.425+0000: 8398: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:29:29.981+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 00:35:06.485+0000: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 00:35:09.645+0000: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 00:37:58.701+0000: 8397: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 00:59:12.925+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 01:04:57.990+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:05:18.031+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:05:37.954+0000: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event +2015-03-06 01:06:13.213+0000: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-03-06 01:06:29.870+0000: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping +2015-03-06 01:06:31.024+0000: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: +2015-03-06 01:06:57.274+0000: 8395: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-0000462a.save. Maybe the file is corrupted? +2015-03-06 01:09:02.581+0000: 8392: error : qemuMonitorIORead:554 : Unable to read from monitor: Connection reset by peer + +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/105/KVM/1456804 b/results/classifier/105/KVM/1456804 new file mode 100644 index 00000000..5d59ff4b --- /dev/null +++ b/results/classifier/105/KVM/1456804 @@ -0,0 +1,340 @@ +KVM: 0.704 +other: 0.680 +vnc: 0.613 +network: 0.604 +boot: 0.588 +instruction: 0.577 +device: 0.570 +mistranslation: 0.557 +graphic: 0.538 +assembly: 0.474 +semantic: 0.447 +socket: 0.414 + +kvm_irqchip_commit_routes: Assertion `ret == 0' failed. + +During win8.1 boot on qemu.git eba05e922e8e7f307bc5d4104a78797e55124e97, kernel 4.1-rc4, I get the following assert: + +qemu-system-x86_64: /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1033: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. + +Bisected to: + +commit 851c2a75a6e80c8aa5e713864d98cfb512e7229b +Author: Jason Wang <email address hidden> +Date: Thu Apr 23 14:21:47 2015 +0800 + + virtio-pci: speedup MSI-X masking and unmasking + + This patch tries to speed up the MSI-X masking and unmasking through + the mapping between vector and queues. With this patch it will there's + no need to go through all possible virtqueues, which may help to + reduce the time spent when doing MSI-X masking/unmasking a single + vector when more than hundreds or even thousands of virtqueues were + supported. + + Tested with 80 queue pairs virito-net-pci by changing the smp affinity + in the background and doing netperf in the same time: + + Before the patch: + 5711.70 Gbits/sec + After the patch: + 6830.98 Gbits/sec + + About 19.6% improvements in throughput. + + Cc: Michael S. Tsirkin <email address hidden> + Signed-off-by: Jason Wang <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + +Backtrace: + +Program received signal SIGABRT, Aborted. +[Switching to Thread 0x7f32fffff700 (LWP 23059)] +0x00007f33187438d7 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007f33187438d7 in raise () at /lib64/libc.so.6 +#1 0x00007f331874553a in abort () at /lib64/libc.so.6 +#2 0x00007f331873c47d in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007f331873c532 in () at /lib64/libc.so.6 +#4 0x000055e0252fed5b in kvm_irqchip_commit_routes (s=0x55e027ce17e0) + at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1033 +#5 0x000055e0252fef46 in kvm_update_routing_entry (s=0x55e027ce17e0, new_entry=0x7f32ffffe4a0) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1078 +#6 0x000055e0252ff78e in kvm_irqchip_update_msi_route (s=0x55e027ce17e0, virq=0, msg=...) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1282 +#7 0x000055e0255899a0 in virtio_pci_vq_vector_unmask (proxy=0x55e02a0ee580, queue_no=2, vector=2, msg=...) at hw/virtio/virtio-pci.c:588 +#8 0x000055e025589b76 in virtio_pci_vector_unmask (dev=0x55e02a0ee580, vector=2, msg=...) at hw/virtio/virtio-pci.c:641 +#9 0x000055e0255186f0 in msix_set_notifier_for_vector (dev=0x55e02a0ee580, vector=2) at hw/pci/msix.c:513 +#10 0x000055e0255187ee in msix_set_vector_notifiers (dev=0x55e02a0ee580, use_notifier=0x55e025589ad2 <virtio_pci_vector_unmask>, release_notifier=0x55e025589c0c <virtio_pci_vector_mask>, poll_notifier=0x55e025589cb1 <virtio_pci_vector_poll>) at hw/pci/msix.c:540 +#11 0x000055e02558a1f0 in virtio_pci_set_guest_notifiers (d=0x55e02a0ee580, nvqs=2, assign=true) at hw/virtio/virtio-pci.c:794 +#12 0x000055e02533c2bc in vhost_net_start (dev=0x55e02a0eef90, ncs=0x55e02a866ac0, total_queues=1) + at /net/gimli/home/alwillia/Work/qemu.git/hw/net/vhost_net.c:318 +#13 0x000055e025336dce in virtio_net_vhost_status (n=0x55e02a0eef90, status=7 '\a') at /net/gimli/home/alwillia/Work/qemu.git/hw/net/virtio-net.c:146 +#14 0x000055e025336e78 in virtio_net_set_status (vdev=0x55e02a0eef90, status=7 '\a') at /net/gimli/home/alwillia/Work/qemu.git/hw/net/virtio-net.c:165 +#15 0x000055e0253504c6 in virtio_set_status (vdev=0x55e02a0eef90, val=7 '\a') + at /net/gimli/home/alwillia/Work/qemu.git/hw/virtio/virtio.c:551 +#16 0x000055e025588d6d in virtio_ioport_write (opaque=0x55e02a0ee580, addr=18, val=7) at hw/virtio/virtio-pci.c:259 +#17 0x000055e0255891d1 in virtio_pci_config_write (opaque=0x55e02a0ee580, addr=18, val=7, size=1) at hw/virtio/virtio-pci.c:385 +#18 0x000055e025303155 in memory_region_write_accessor (mr=0x55e02a0eee00, addr=18, value=0x7f32ffffe908, size=1, shift=0, mask=255, attrs=...) + at /net/gimli/home/alwillia/Work/qemu.git/memory.c:457 +#19 0x000055e025303308 in access_with_adjusted_size (addr=18, value=0x7f32ffffe908, size=1, access_size_min=1, access_size_max=4, access= + 0x55e0253030d0 <memory_region_write_accessor>, mr=0x55e02a0eee00, attrs=...) at /net/gimli/home/alwillia/Work/qemu.git/memory.c:516 +#20 0x000055e025305b15 in memory_region_dispatch_write (mr=0x55e02a0eee00, addr=18, data=7, size=1, attrs=...) + at /net/gimli/home/alwillia/Work/qemu.git/memory.c:1166 +#21 0x000055e0252b68eb in address_space_rw (as=0x55e025b71a80 <address_space_io>, addr=49458, attrs=..., buf=0x7f3322f48000 "\a", len=1, is_write=true) + at /net/gimli/home/alwillia/Work/qemu.git/exec.c:2363 +#22 0x000055e02530041e in kvm_handle_io (port=49458, attrs=..., data=0x7f3322f48000, direction=1, size=1, count=1) + at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1679 +#23 0x000055e025300914 in kvm_cpu_exec (cpu=0x55e02a1383a0) +---Type <return> to continue, or q <return> to quit--- + at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1839 +#24 0x000055e0252e8062 in qemu_kvm_cpu_thread_fn (arg=0x55e02a1383a0) + at /net/gimli/home/alwillia/Work/qemu.git/cpus.c:947 +#25 0x00007f3321b2352a in start_thread () at /lib64/libpthread.so.0 +#26 0x00007f331880f22d in clone () at /lib64/libc.so.6 + +VM XML (-snapshot added only for bisect): + +<domain type='kvm' id='8' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <name>Steam</name> + <uuid>79f39860-d659-426b-89e8-90cb46ee57c6</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <memoryBacking> + <hugepages/> + </memoryBacking> + <vcpu placement='static'>4</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='0'/> + <vcpupin vcpu='1' cpuset='1'/> + <vcpupin vcpu='2' cpuset='2'/> + <vcpupin vcpu='3' cpuset='3'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'>/var/lib/libvirt/qemu/nvram/Steam_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <pae/> + <kvm> + <hidden state='on'/> + </kvm> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='4' threads='1'/> + </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/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none' io='native'/> + <source file='/mnt/store/vm/Steam.qcow2'/> + <backingStore type='file' index='1'> + <format type='raw'/> + <source file='/mnt/store/vm/Steam.img'/> + <backingStore/> + </backingStore> + <target dev='sda' bus='scsi'/> + <boot order='2'/> + <alias name='scsi0-0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='scsi' index='0' model='virtio-scsi'> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb0'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb0'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb0'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:60:ef:ac'/> + <source bridge='br0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> + </source> + <alias name='hostdev1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </hostdev> + <memballoon model='none'> + <alias name='balloon0'/> + </memballoon> + </devices> + <qemu:commandline> + <qemu:arg value='-snapshot'/> + </qemu:commandline> +</domain> + +From the trace, looks like the driver is trying to assign config vq (2) an vector(2). This is interesting. + +I try to reproduce but fail. (The only difference is my guest does not have any vfio and ovmf was not used). + +Can you reproduce it without ovmf and vfio? + +Thanks + +The bug is unaffected, it still occurs, by removing the vfio devices from the config and replacing them with a standard spice/qxl graphics setup. I'm unable to reproduce the issue so far using a seabios-based win8.1 install. + +Correction, I was using the stock distro qemu-kvm. Yes, the problem occurs on a stock seabios win8.1 VM without vfio: + +<domain type='kvm'> + <name>win8.1</name> + <uuid>896cb319-c196-4b92-a7e2-2306b0eac769</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + </os> + <features> + <acpi/> + <apic/> + <pae/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + </hyperv> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>SandyBridge</model> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/mnt/store/vm/win8.1-seabios'/> + <target dev='sda' bus='scsi'/> + <boot order='2'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='bridge'> + <mac address='52:54:00:c9:7b:49'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' autoport='yes'> + <image compression='off'/> + </graphics> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </memballoon> + </devices> +</domain> + + +Using almost the same XML but still could not reproduce this by myself. + +What's the version of guest driver inside? I'm using 12/19/2014 62.70.104.9800? + +I'm using 62.72.104.10300. I started with the old virtio-win-0.1-100 ISO, but I couldn't figure out how to downgrade to the latest "stable" release, so instead I upgraded to the 103 release to see if it fixed anything. It does not. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +This appears to address it in QEMU v2.4: + +commit 6652d0811c9463fbfb2d2d1cb2ec03f388145c5f +Author: Jason Wang <email address hidden> +Date: Wed May 27 16:26:07 2015 +0800 + + virtio-pci: don't try to mask or unmask vqs without notifiers + + We should validate the vq index against nvqs_with_notifiers. Otherwise we may + try to mask or unmask vector for vqs without notifiers (e.g control vq). This + will lead qemu abort on kvm_irqchip_commit_routes() when trying to boot win8.1 + guest. + + Fixes 851c2a75a6e80c8aa5e713864d98cfb512e7229b ("virtio-pci: speedup MSI-X + masking and unmasking") + + Reported-by: Alex Williamson <email address hidden> + Signed-off-by: Jason Wang <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + + diff --git a/results/classifier/105/KVM/1463143 b/results/classifier/105/KVM/1463143 new file mode 100644 index 00000000..389392d3 --- /dev/null +++ b/results/classifier/105/KVM/1463143 @@ -0,0 +1,126 @@ +KVM: 0.843 +other: 0.803 +mistranslation: 0.738 +device: 0.717 +graphic: 0.712 +instruction: 0.694 +semantic: 0.681 +vnc: 0.665 +boot: 0.648 +assembly: 0.647 +network: 0.641 +socket: 0.577 + +Kernel Panic on Guest VM + +Hi, + +I've recently attempted to move a stack to qemu vm's that I have run successfully on both hard metal and ec2. + +I'm not sure where to even begin debugging, could someone please point me in the right direction? + + + + + [781785.483343] RIP: 0010:[<ffffffff81511830>] [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780 +[781785.483345] RSP: 0000:ffff88007fd03dd0 EFLAGS: 00010097 +[781785.483346] RAX: 0000000000000000 RBX: ffff8800374d0000 RCX: 0000000000000050 +[781785.483347] RDX: 0000000000000006 RSI: ffff8800374d0158 RDI: ffff8800374d0000 +[781785.483348] RBP: ffff88007fd03e20 R08: 0000000000000086 R09: ffff88007cc00000 +[781785.483349] R10: 0000000000000011 R11: 000000000000000b R12: ffff8800374d0158 +[781785.483350] R13: 0000000000000000 R14: ffff8800374d0158 R15: ffff8800374d0208 +[781785.483356] FS: 00007f3882e75700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 +[781785.483357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[781785.483358] CR2: 00007f37df39a000 CR3: 000000000b7a5000 CR4: 00000000000006e0 +[781785.483369] Stack: +[781785.483373] ffff8800373cb000 ffff88007fd03e60 ffffffff8108d7d2 ffff88007fd03e28 +[781785.483375] ffff8800374d2140 ffff8800374d0000 ffff8800374d0158 0000000000000000 +[781785.483378] 0000000000000050 0000000000000000 ffff88007fd03e50 ffffffff81511e96 +[781785.483378] Call Trace: +[781785.483382] <IRQ> +[781785.483396] [<ffffffff8108d7d2>] ? run_posix_cpu_timers+0x42/0x5c0 +[781785.483400] [<ffffffff81511e96>] __ata_sff_port_intr+0x96/0x120 +[781785.483403] [<ffffffff815121ed>] ata_bmdma_port_intr+0x2d/0x120 +[781785.483405] [<ffffffff81512ba3>] ata_bmdma_interrupt+0x183/0x1e0 +[781785.483414] [<ffffffff810bf8be>] handle_irq_event_percpu+0x3e/0x1d0 +[781785.483433] [<ffffffff810bfa8d>] handle_irq_event+0x3d/0x60 +[781785.483437] [<ffffffff810c2517>] handle_edge_irq+0x77/0x130 +[781785.483455] [<ffffffff81015cde>] handle_irq+0x1e/0x30 +[781785.483472] [<ffffffff817312cd>] do_IRQ+0x4d/0xc0 +[781785.483476] [<ffffffff81726a6d>] common_interrupt+0x6d/0x6d +[781785.483478] <EOI> +[781785.483480] [<ffffffff8172efad>] ? system_call_fastpath+0x1a/0x1f +[781785.483498] Code: f9 ff ff 41 0f b6 46 28 3c 06 0f 84 0b 03 00 00 3c 07 0f 84 e3 02 00 00 3c 05 0f 84 c3 02 00 00 0f 0b 66 0f 1f 84 00 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 f6 c1 08 0f 84 19 05 00 00 f6 c1 21 0f +[781785.483501] RIP [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780 +[781785.483501] RSP <ffff88007fd03dd0> +[781785.484009] ---[ end trace 1b6ef3497a5641b3 ]--- +[781785.484009] Kernel panic - not syncing: Fatal exception in interrupt +[781785.484009] Shutting down cpus with NMI + + +Thanks for any pointers. + +Ryan + +On Mon, Jun 08, 2015 at 07:13:56PM -0000, ryan wrote: +> Public bug reported: +> +> Hi, +> +> I've recently attempted to move a stack to qemu vm's that I have run +> successfully on both hard metal and ec2. +> +> I'm not sure where to even begin debugging, could someone please point +> me in the right direction? +> +> +> [781785.483343] RIP: 0010:[<ffffffff81511830>] [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780 +> [781785.483345] RSP: 0000:ffff88007fd03dd0 EFLAGS: 00010097 +> [781785.483346] RAX: 0000000000000000 RBX: ffff8800374d0000 RCX: 0000000000000050 +> [781785.483347] RDX: 0000000000000006 RSI: ffff8800374d0158 RDI: ffff8800374d0000 +> [781785.483348] RBP: ffff88007fd03e20 R08: 0000000000000086 R09: ffff88007cc00000 +> [781785.483349] R10: 0000000000000011 R11: 000000000000000b R12: ffff8800374d0158 +> [781785.483350] R13: 0000000000000000 R14: ffff8800374d0158 R15: ffff8800374d0208 +> [781785.483356] FS: 00007f3882e75700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 +> [781785.483357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +> [781785.483358] CR2: 00007f37df39a000 CR3: 000000000b7a5000 CR4: 00000000000006e0 +> [781785.483369] Stack: +> [781785.483373] ffff8800373cb000 ffff88007fd03e60 ffffffff8108d7d2 ffff88007fd03e28 +> [781785.483375] ffff8800374d2140 ffff8800374d0000 ffff8800374d0158 0000000000000000 +> [781785.483378] 0000000000000050 0000000000000000 ffff88007fd03e50 ffffffff81511e96 +> [781785.483378] Call Trace: +> [781785.483382] <IRQ> +> [781785.483396] [<ffffffff8108d7d2>] ? run_posix_cpu_timers+0x42/0x5c0 +> [781785.483400] [<ffffffff81511e96>] __ata_sff_port_intr+0x96/0x120 +> [781785.483403] [<ffffffff815121ed>] ata_bmdma_port_intr+0x2d/0x120 +> [781785.483405] [<ffffffff81512ba3>] ata_bmdma_interrupt+0x183/0x1e0 +> [781785.483414] [<ffffffff810bf8be>] handle_irq_event_percpu+0x3e/0x1d0 +> [781785.483433] [<ffffffff810bfa8d>] handle_irq_event+0x3d/0x60 +> [781785.483437] [<ffffffff810c2517>] handle_edge_irq+0x77/0x130 +> [781785.483455] [<ffffffff81015cde>] handle_irq+0x1e/0x30 +> [781785.483472] [<ffffffff817312cd>] do_IRQ+0x4d/0xc0 +> [781785.483476] [<ffffffff81726a6d>] common_interrupt+0x6d/0x6d +> [781785.483478] <EOI> +> [781785.483480] [<ffffffff8172efad>] ? system_call_fastpath+0x1a/0x1f +> [781785.483498] Code: f9 ff ff 41 0f b6 46 28 3c 06 0f 84 0b 03 00 00 3c 07 0f 84 e3 02 00 00 3c 05 0f 84 c3 02 00 00 0f 0b 66 0f 1f 84 00 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 f6 c1 08 0f 84 19 05 00 00 f6 c1 21 0f +> [781785.483501] RIP [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780 +> [781785.483501] RSP <ffff88007fd03dd0> +> [781785.484009] ---[ end trace 1b6ef3497a5641b3 ]--- +> [781785.484009] Kernel panic - not syncing: Fatal exception in interrupt +> [781785.484009] Shutting down cpus with NMI + +Please post your QEMU command-line. + +For best performance with a raw disk image file on local storage use: + -drive if=none,file=path/to/disk.img,format=raw,aio=native,cache=none,id=drive0 -device virtio-blk-pci,drive=drive0 + +That may also work around this ATA issue. + +Stefan + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? If so, please provide the command line parameters that you use! + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1465935 b/results/classifier/105/KVM/1465935 new file mode 100644 index 00000000..baa54639 --- /dev/null +++ b/results/classifier/105/KVM/1465935 @@ -0,0 +1,302 @@ +KVM: 0.818 +vnc: 0.808 +mistranslation: 0.802 +other: 0.755 +device: 0.728 +instruction: 0.717 +graphic: 0.711 +assembly: 0.711 +semantic: 0.706 +boot: 0.656 +network: 0.643 +socket: 0.618 + +kvm_irqchip_commit_routes: Assertion `ret == 0' failed + +Several my QEMU instances crashed, and in the qemu log, I can see this assertion failure, + + qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/kvm-all.c:984: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. + +The QEMU version is 2.0.0, HV OS is ubuntu 12.04, kernel 3.2.0-38. Guest OS is RHEL 6.3. + +The problem can be re-produced by the script in the below in link. +http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg03739.html + +i.e. +vda_irq_num=25 +vdb_irq_num=27 +while [ 1 ] +do + for irq in {1,2,4,8,10,20,40,80} + do + echo $irq > /proc/irq/$vda_irq_num/smp_affinity + echo $irq > /proc/irq/$vdb_irq_num/smp_affinity + dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct + dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct + done +done + +http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg03739.html + +Seems that this patch hasn't been accpeted yet, and also no comments for it. + +From the debug log, we can see that virq is only 1008, but irq route table has been full, i.e. 1024. +In kvm_irqchip_get_virq(), it only calls kvm_flush_dynamic_msi_routes() when all virqs(total gsi_count, 1024 too) have been allocated, but irq route table has two kind of entry type, KVM_IRQ_ROUTING_IRQCHIP and KVM_IRQ_ROUTING_MSI. Seems that 16 KVM_IRQ_ROUTING_IRQCHIP entries has been reserved, if max gsi_count is still 1024, then irq route table is possible to be overflow. +The fix could be either set gsi_cout=1008 or increase max irq route count to 1040. + +kvm_irqchip_send_msi, virq=1008, nr=1024 +kvm_irqchip_commit_routes, ret=-22 +kvm_irqchip_commit_routes, irq_routes nr=1024 + +From kvm_pc_setup_irq_routing() function, we can see that 15 routes from PIC and 23 routes from IOAPIC are added into irq route table, but only 23 irq(gsi) are reserved. This leads to irq route table has been full but there are still tens of free gsi. So the "retry" part of kvm_irqchip_get_virq() shall never have chance to be executed. + + + +void kvm_pc_setup_irq_routing(bool pci_enabled) +{ + KVMState *s = kvm_state; + int i; + + if (kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) { + for (i = 0; i < 8; ++i) { + if (i == 2) { + continue; + } + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_PIC_MASTER, i); + } + for (i = 8; i < 16; ++i) { + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_PIC_SLAVE, i - 8); + } + if (pci_enabled) { + for (i = 0; i < 24; ++i) { + if (i == 0) { + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_IOAPIC, 2); + } else if (i != 2) { + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_IOAPIC, i); + } + } + } + kvm_irqchip_commit_routes(s); + } +} + +static int kvm_irqchip_get_virq(KVMState *s) +{ + uint32_t *word = s->used_gsi_bitmap; + int max_words = ALIGN(s->gsi_count, 32) / 32; + int i, bit; + bool retry = true; + +again: + /* Return the lowest unused GSI in the bitmap */ + for (i = 0; i < max_words; i++) { + bit = ffs(~word[i]); + if (!bit) { + continue; + } + + return bit - 1 + i * 32; + } + if (!s->direct_msi && retry) { + retry = false; + kvm_flush_dynamic_msi_routes(s); + goto again; + } + return -ENOSPC; + +} + + + +Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal: + +apport-collect 1465935 + +When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs. + +It appears that the latest version of the patch is here: + +http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00822.html + +However, this hasn't yet be accepted upstream. The most recent discussion requires the submitter to respond to the maintainers questions here: + +http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00623.html + + + +Have you be able to reproduce this issue on a wily host? What about a different guest? Or is only RHEL6.3 affected? + +Ryan, +Our Hypervisors are running in the internal network which can't access to Launchpad, +# apport-collect 1465935 +ERROR: connecting to Launchpad failed: [Errno 110] Connection timed out + +We saw this qemu crash on 18 Hypervisor nodes. So far all our hypervisors are ubuntu 12.04, qemu-2.0.0+dfsg, and guest OS is only RHEL6.3 + + +http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00822.html + +Seems that the latest version code has answered maintainers questions. + + +-----Original Message----- +From: Paolo Bonzini [mailto:<email address hidden>] +Sent: 2015年7月1日 21:39 +To: Li, Chengyuan +Cc: <email address hidden> +Subject: Re: [Qemu-devel] [PATCH] Fix irq route entries exceed KVM_MAX_IRQ_ROUTES + +On 30/06/2015 05:47, Li, Chengyuan wrote: +> Here is my understanding, +> +> 1) why isn't the existing check in kvm_irqchip_get_virq enough to fix +> the bug? +> +> From kvm_pc_setup_irq_routing() function, we can see that 15 routes +> from PIC and 23 routes from IOAPIC are added into irq route table, but +> only +> 23 irq(gsi) are reserved. This leads to irq route table has been full +> but there are still 15 free gsi. So the "retry" part of +> kvm_irqchip_get_virq() shall never have chance to be executed. +> +> 2) If you introduce this extra call to kvm_flush_dynamic_msi_routes, +> does the existing check become obsolete? +> +> As gsi_count is the max number of irq route table, if below code is +> merged, then existing check is obsolete and can be removed. +> +> + if (!s->direct_msi && s->irq_routes->nr == s->gsi_count) { +> + kvm_flush_dynamic_msi_routes(s); +> + } +> +> Please let me know if you have some other comments for the patch? Thanks! + +Thanks for finally clearing up my doubts about the patch! I'll apply it soon. + +Paolo + + +The proposed fix seems not yet part of any qemu release but applied as + +commit bdf026317daa3b9dfa281f29e96fbb6fd48394c8 +Author: 马文霜 <email address hidden> +Date: Wed Jul 1 15:41:41 2015 +0200 + + Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES + +to v2.4.0-rc0. So this would affect all current releases and the current development release (Wily/15.10). I would start there with reproduction/verification and work backwards from there. + +Unfortunately I seem to be unable to get this bug triggered with the reproducer. It could be a detail of the guest setup I am missing. Since I do not have access to RHEL I used CentOS 6.3 in a 8core guest with 2 virtio disks. Host was 14.04. Left the script running for quite a bit but no crash happened. +So it would be up to you to confirm that with a current 14.04 host you still can trigger the bug and with the patched version of qemu from http://people.canonical.com/~smb/lp1465935/ it would be gone. Thanks. + +Bader, + +Sorry to response late. +We patch our QEMU 2.0 and running on ubuntu 12.04, and shall keep it running for a while. +I'll let you know if this problem is gone after weeks. + +Regards, +CY. + +Marking as incomplete while waiting for test feedback. + +Bader, + +We don't see this problem after the patch is applied. I think we can close this case. + +Regards, +CY. + +Utopic is out of support now. + +SRU Justification: + +Impact: Moving around interrupt handling on SMP (like irqbalance does) in qemu instances can cause the qemu guest to crash due to an internal accounting mismatch. + +Fix: Backported patch from upstream qemu + +Testcase: See above. Verified for Trusty with provided test qemu package(s). + +@Li Chengyuan, is your host OS really 12.04 (aka Precise)? Because in 12.04 the qemu version is 1.0 and the fix would not apply. I am not sure that old qemu is even affected since the code is very different. Backports of the fix seem only to make sense up (or back) to 14.04 (aka Trusty) which would also match the qemu version 2.0 which you mentioned. + +Just saw kernel version 3.2 mentioned. So this seems to be a mix of older base OS (Precise) and a more recent qemu (maybe from Trusty). I am trying to clarify how far this needs to be backported. So I think the original qemu version in Precise is unaffected. + +This bug was fixed in the package qemu - 1:2.3+dfsg-5ubuntu9 + +--------------- +qemu (1:2.3+dfsg-5ubuntu9) wily; urgency=low + + * debian/patches/upstream-fix-irq-route-entries.patch + Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed" + (LP: #1465935) + + -- Stefan Bader <email address hidden> Fri, 09 Oct 2015 15:38:53 +0200 + +@Stefan Bader, +The host OS is ubuntu 12.04, and we upgraded the QEMU to 2.0.0 from ubuntu cloud-archive repo. +https://wiki.ubuntu.com/ServerTeam/CloudArchive + +@Li Chengyuan, thank you for the clarification. So just formally I will mark the Precise task of this report as invalid (since the qemu in Precise is actually a different source package and also not affected as far as I can tell). I will need to figure out how to ensure this fix is also pulled into the cloud-archive after it landed in the Trusty/Vivid main archive. + +Hello Li, 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.20 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 Li, or anyone else affected, + +Accepted qemu into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.2+dfsg-5expubuntu9.6 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! + +@chengyuanli + +could you please verify this? + +This package is causing a regression in lp:qa-regression-testing's +scripts/test-qemu.py. + +I'm running the testcase one more time (after having verified that the +current package did not suffer the same failure), then I'm going to mark this +verification-failed. + + +Hm, a second run did not reproduce the error. If I can't get it to happen again in a few hours of re-trying, I'll assume it was a fluke or related to the host. + +I could not reproduce the original issue, but the new qemu packages appear to be regression-free, so marked this verification-done on that grounds. If the SRU team prefers to kick this package I'm ok with that as well. + +Fixed in QEMU 2.4. + +This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.20 + +--------------- +qemu (2.0.0+dfsg-2ubuntu1.20) trusty; urgency=low + + * debian/patches/upstream-fix-irq-route-entries.patch + Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed" + (LP: #1465935) + + -- Stefan Bader <email address hidden> Fri, 09 Oct 2015 17:16:30 +0200 + +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 - 1:2.2+dfsg-5expubuntu9.6 + +--------------- +qemu (1:2.2+dfsg-5expubuntu9.6) vivid; urgency=low + + * debian/patches/upstream-fix-irq-route-entries.patch + Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed" + (LP: #1465935) + + -- Stefan Bader <email address hidden> Fri, 09 Oct 2015 17:04:26 +0200 + diff --git a/results/classifier/105/KVM/1470481 b/results/classifier/105/KVM/1470481 new file mode 100644 index 00000000..4a578666 --- /dev/null +++ b/results/classifier/105/KVM/1470481 @@ -0,0 +1,27 @@ +KVM: 0.869 +device: 0.743 +graphic: 0.734 +instruction: 0.626 +semantic: 0.456 +mistranslation: 0.431 +boot: 0.374 +vnc: 0.362 +socket: 0.347 +network: 0.245 +assembly: 0.180 +other: 0.118 + +qemu-img converts large vhd files into only approx. 127GB raw file causing the VM to crash + +I have a VHD file for Windows 2014 server OS. I use the following command to convert VHD file (20GB) to a RAW file for KVM. + +qemu-img convert -f vpc -O raw WIN-SNRGCQV6O3O.VHD disk.img + +The output file is about 127GB. When install the VM and boot it up, the OS crashes with STOP error after the intial screen. I found on the internet that the file limit of 127GB is an existing bug. Kindly fix the problem. The workaround to use a Hyper-V to convert to fixed disk is not a feasible solution. + +Which version of QEMU (or rather qemu-img) have you been using here? Can you still reproduce it with the latest version (currently v2.12)? + +I have qemu-img 1.4.1 included in Suse Linux Enterprise server version 11 SP3. I will see whether I can update it and then try the conversion and post the results. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1481375 b/results/classifier/105/KVM/1481375 new file mode 100644 index 00000000..04b48a43 --- /dev/null +++ b/results/classifier/105/KVM/1481375 @@ -0,0 +1,43 @@ +KVM: 0.779 +boot: 0.666 +graphic: 0.606 +device: 0.515 +socket: 0.361 +assembly: 0.301 +semantic: 0.270 +other: 0.253 +mistranslation: 0.247 +network: 0.234 +vnc: 0.194 +instruction: 0.123 + +Windows 7 Pro - Sticky Keys + +Qemu KVM v: 1.1.0 +CentOS 7: 3.10.0-229.7.2.el7.x86_64 +Lenovo Thinkpad Yoga + +USB devices: +Bus 001 Device 002: ID 8087:8000 Intel Corp. +Bus 002 Device 068: ID 2109:3431 +Bus 002 Device 012: ID 8087:07dc Intel Corp. +Bus 002 Device 004: ID 04f3:0254 Elan Microelectronics Corp. +Bus 002 Device 005: ID 04f2:b39f Chicony Electronics Co., Ltd +Bus 003 Device 047: ID 2109:0811 +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +Bus 001 Device 003: ID 0483:91d1 STMicroelectronics +Bus 001 Device 004: ID 056a:00ec Wacom Co., Ltd +Bus 002 Device 069: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse +Bus 002 Device 070: ID 04f2:0112 Chicony Electronics Co., Ltd KU-8933 Keyboard with PS/2 Mouse port +Bus 002 Device 071: ID 2109:3431 +Bus 003 Device 048: ID 2109:0811 +Bus 003 Device 049: ID 17e9:4302 DisplayLink + +CentOS (host OS) does not register stuck keys, primarily CTRL, ALT, Windows Key, and escape. Windows 7 Pro VM keeps getting sticky keys registered when I boot into the OS or randomly bring back up the console. The keys getting stuck are CTRL, L_SHIFT, ALT, or Windows key, maybe escape. I have to frantically repress the primary shortcut keys on both the USB keyboard and the laptop keyboard. The USB keyboard is mechanical and clean. The laptop is new. Remember, the host OS does not register stuck keys. If anyone has had this problem, or knows a trick to prevent sticky keys, I'm all ears. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU (currently v2.12)? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1484 b/results/classifier/105/KVM/1484 new file mode 100644 index 00000000..e80a28aa --- /dev/null +++ b/results/classifier/105/KVM/1484 @@ -0,0 +1,42 @@ +KVM: 0.718 +mistranslation: 0.708 +vnc: 0.672 +graphic: 0.628 +instruction: 0.617 +other: 0.616 +boot: 0.532 +semantic: 0.532 +assembly: 0.532 +device: 0.493 +network: 0.399 +socket: 0.394 + +cachy linux iso not booting in linux, host machine freezes +Description of problem: +- cachyos-gnome-linux-230121.iso + - boots native (core-i7 haswell) via ventoy-boot + - boots on windows (Win10 22H2 19045.2546) using + ``` + qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios E:\vstorage\win_m01_edk2-x8_64.fd -boot d -cdrom E:/transcend/cachyos-gnome-linux-230121.iso -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -device virtio-serial -chardev socket,path=C:/tmpq/Downloads/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait" + ``` + - does not boot on Linux. Infact it crashes the host, which is a much bigger problem + ``` + qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/m20_OVMF_VARS.fd" -cdrom /vol/15KJ_Images/transcend/cachyos-gnome-linux-230121.iso -device virtio-vga-gl -display "spice-app,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -device virtio-serial -chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait + ``` + when qemu windows pops up graphics inside the popped up virtviewer spice VM-window is garbled, seemingly of the grub2 bootscreen. + Initially, after window popup the mouse pointer can move for a few more seconds. + Then host machine GUI freezes + Then caps lock toggle/LED works for a while + Then host machine itself freezes. Even Ctrl-Alt-Fx to linux-console does not work. + Then forced to long-press power button and reboot + +Its one thing for the qemu to not be able to boot VM/iso, Its a whole different level bug to freeze the host-machine. +Fault inside VM should not affect outside. Plus, I think, I ran qemu-system-x86-64 as ordinary user and not as root. + +The self-built qemu-7.2.0 from handcrafted srpm has worked well with my other images. + +It may have something to do with virtio-vga-gl in linux but will need to test on next reboot to linux. +Steps to reproduce: +1. just run qemu command on linux +Additional information: + diff --git a/results/classifier/105/KVM/1500935 b/results/classifier/105/KVM/1500935 new file mode 100644 index 00000000..56b4022e --- /dev/null +++ b/results/classifier/105/KVM/1500935 @@ -0,0 +1,32 @@ +KVM: 0.918 +graphic: 0.780 +device: 0.679 +mistranslation: 0.676 +instruction: 0.621 +other: 0.617 +semantic: 0.559 +socket: 0.256 +vnc: 0.256 +network: 0.248 +assembly: 0.233 +boot: 0.201 + +Qemu / KVM always wants to be on top + +Whenever I pass with the mouse over the KVM (qemu) window, it automatically raises on top, obscuring other windows on the same desktop, which is rather intrusive... +No other application does this. + +> dpkg -l qemu-kvm +Desired=Unknown/Install/Remove/Purge/Hold +| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend +|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) +||/ Name Version Architecture Description ++++-==============-============-============-================================= +ii qemu-kvm 2.0.0+dfsg-2 amd64 QEMU Full virtualization + +Seems like you are using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + +Seems to be fixed by now. Indeed kvm no longer does this on none of the 2 distributions that I currently use (Debian 8.6.0 and Kubuntu 14.04.5) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1502884 b/results/classifier/105/KVM/1502884 new file mode 100644 index 00000000..cd96d06e --- /dev/null +++ b/results/classifier/105/KVM/1502884 @@ -0,0 +1,60 @@ +KVM: 0.557 +vnc: 0.463 +semantic: 0.457 +network: 0.447 +other: 0.438 +graphic: 0.416 +device: 0.416 +instruction: 0.377 +assembly: 0.349 +mistranslation: 0.302 +socket: 0.301 +boot: 0.235 + +Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option! + +Hi, + +A big issue when using QEMU's VNC server (VNC KVM) is that, when there's a network lag, unintended keypresses go through to the QEMU guest VM. + +This is frequently "enter" keypresses, causing all kinds of unintended consequences in the VM. So basically it's extremely dangerous. + +This is because the VNC protocol's keyboard interaction is implemented in terms of key down - key up events, making the server's keyboard autorepeat kick in when it should not. + + +For this reason, it would be great if QEMU's VNC server part would be enhanced with an option such that when a VNC protocol key down is received, then locally that is treated as one single keypress only (I don't know how that should be implemented but I guess either as an immediate key down - key up sequence locally, or key down + key up after say 0.05 seconds), instead of waiting for the key up event from the VNC client. + +Thanks! + +What I request seems to be the same option as x11vnc's "-norepeat", http://linux.die.net/man/1/x11vnc + +... this doesn't seem to be a VNC-only issue.. I get quite the big of repeat/stuck key presses with the GTK frontend as well.. Also, lines like these frequently show up in the logs: + +> [15512.846716] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [15513.031586] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [15513.931140] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [15513.935319] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [15994.802058] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [15994.807817] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18243.163746] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18243.165704] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18243.372671] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18243.374203] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18576.754033] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18576.771257] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18584.556247] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18585.168172] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [18628.989958] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [18628.992058] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. +> [20227.153135] psmouse serio1: VMMouse at isa0060/serio1/input0 lost sync at byte 1 +> [20227.161066] psmouse serio1: VMMouse at isa0060/serio1/input0 - driver resynced. + + +The VNC server doesn't get involved in key repeat functionality, it just passes keys from the client onto the guest OS. The client can indicate that it is doing key repeat by sending a series of "key down" events, and only 1 "key up" event to indicate end of auto-repeat. The guest OS can itself implement auto-repeat at any frequency it wishes by watching the key stream. The "-norepeat" option to X11 VNC that is referred to here isn't something related to the VNC part of x11vnc, but rather it appears related to the X11 part which corresponds to the guest OS in QEMU's case. I don't see there is much QEMU can do here. + +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/105/KVM/1502934 b/results/classifier/105/KVM/1502934 new file mode 100644 index 00000000..9cd7f2ec --- /dev/null +++ b/results/classifier/105/KVM/1502934 @@ -0,0 +1,42 @@ +KVM: 0.913 +instruction: 0.822 +mistranslation: 0.817 +device: 0.782 +other: 0.770 +graphic: 0.743 +semantic: 0.716 +boot: 0.529 +network: 0.378 +vnc: 0.371 +socket: 0.307 +assembly: 0.262 + +QEMU does not start when kvm enabled (SMM issue?) + +Hi! + +QEMU stopped working after "[355023f2010c4df619d88a0dd7012b4b9c74c12c] pc: add SMM property" on my server. It says "Guest has not initialized the display (yet)." and nothing happens. But only if I use -enable-kvm. + +However, the problem gone after I hardcoded pc_machine_is_smm_enabled() to always return false (but I have little to no understanding of what SMM really is). + +CMD line that reproduces the issue: qemu-system-x86_64 -enable-kvm -display curses . It doesn't work the server, but works perfectly on my laptop :(. + +I'm using Arch Linux with all updates. +Some info: +Linux machine 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux +Qemu-2.4.0 (tried HEAD as well) +CPU: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz +Some messages from dmesg, just in case: +[ 6.996297] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround +[ 6381.722990] kvm: zapping shadow pages for mmio generation wraparound + + +I'm more than happy to provide additional information if needed. + +Cheers, +Alex + +This is a KVM bug, not a QEMU bug. It only happens with ept=1 and unrestricted_guest=0. A workaround is to disable SMM in QEMU (-machine smm=off) or to set kvm_intel's ept parameter to 0. + +I'm closing the bug here because it is the wrong tracker (also I know about it, can reproduce, and hope to provide a fix later this week). + diff --git a/results/classifier/105/KVM/1518969 b/results/classifier/105/KVM/1518969 new file mode 100644 index 00000000..4b19315d --- /dev/null +++ b/results/classifier/105/KVM/1518969 @@ -0,0 +1,49 @@ +KVM: 0.731 +other: 0.684 +vnc: 0.680 +mistranslation: 0.677 +device: 0.674 +socket: 0.674 +graphic: 0.667 +assembly: 0.667 +instruction: 0.661 +boot: 0.659 +network: 0.658 +semantic: 0.656 + +Instance of QEMU doesn't unplug virtio scsi disk after device_del and drive_del commands + +device_del and drive_del commands don't cause virtio disk detaching + +Steps to reproduce: +1. Run instance + +2. Attach virtio scsi disk + +3. Reboot instance + +4. Immediately after reboot detach disk with QEMU commands: +device_del +drive_del + +Expected result: +Disk should be detached anyway + +Actual: +Domain info contains attached disk even after waiting long period of time(5 min in my case). + +Additional info: +QEMU process: +root 29010 42.6 1.9 562036 61272 ? Rl 03:42 0:01 /usr/bin/qemu-system-x86_64 -name instance-00000069 -S -machine pc-i440fx-trusty,accel=tcg,usb=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid d2418536-2547-4740-96b5-0d4f1d74b9f3 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=1fd8f69a-909b-4ed1-aae9-4fc9318fc622,uuid=d2418536-2547-4740-96b5-0d4f1d74b9f3,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000069.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/kernel -initrd /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/ramdisk -append root=/dev/vda console=tty0 console=ttyS0 no_timer_check -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk.config,if=none,id=drive-ide0-1-1,readonly=on,format=raw,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=18,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:1a:10:3d,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +QEMU version: +qemu-system-x86_64 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.19), Copyright (c) 2003-2008 Fabrice Bellard + +Maybe you detach disk too fast.When you detach disk,the guest os maybe has not loaded the hotplug modules.So it can not detect your detach event.Can you test the situation when detaching disk after guest os starting up ? + +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/105/KVM/1529187 b/results/classifier/105/KVM/1529187 new file mode 100644 index 00000000..a573cb84 --- /dev/null +++ b/results/classifier/105/KVM/1529187 @@ -0,0 +1,56 @@ +KVM: 0.945 +semantic: 0.944 +device: 0.931 +graphic: 0.928 +instruction: 0.925 +mistranslation: 0.892 +other: 0.887 +network: 0.858 +socket: 0.815 +assembly: 0.815 +vnc: 0.787 +boot: 0.691 + +vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform + +Environment: + ------------ + Host OS (ia32/ia32e/IA64): ia32e + Guest OS (ia32/ia32e/IA64): ia32e + Guest OS Type (Linux/Windows): linux + kvm.git Commit: da3f7ca3 + qemu.git Commit: 38a762fe + Host Kernel Version: 4.4.0-rc2 + Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP) + +Bug description: + -------------------------- + when create guest with vt-d assignment using vfio-pci driver, the guest can not be created. +Warning 'No available IOMMU models' + + +Reproduce steps: + ---------------- + 1. bind device to vfio-pci driver + 2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device vfio-pci,host=81:00.0 -net none -drive file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + +Current result: + ---------------- + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU models + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup container for group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization failed + +Expected result: + ---------------- + guest can be created +Basic root-causing log: + ---------------------- + + + + +You've somehow managed to not load the vfio_iommu_type1 module. The vfio module will request it when loading, if the module is not available when loading, such as from an initramfs that does not include the full set of vfio modules, it will need to be loaded later manually. + +You're right. After I manually load vfio_iommu_type1, the error is gone. + diff --git a/results/classifier/105/KVM/1532 b/results/classifier/105/KVM/1532 new file mode 100644 index 00000000..7a5d2731 --- /dev/null +++ b/results/classifier/105/KVM/1532 @@ -0,0 +1,516 @@ +KVM: 0.904 +device: 0.850 +vnc: 0.848 +network: 0.842 +other: 0.831 +graphic: 0.818 +boot: 0.803 +mistranslation: 0.799 +assembly: 0.763 +instruction: 0.752 +semantic: 0.720 +socket: 0.684 + +libivrtd fork qemu to create vm ,which start with ceph rbd device, after vm status:runing , the qemu stuck at booting from hard disk.... +Description of problem: +[root@ceph-client ceph]# virsh list --all + Id Name State +---------------------------------------------------- + 19 c7_ceph running + +the vm qemu stuck at booting from hard disk..... +Steps to reproduce: +1. use ceph-deploy deploy a ceph distribute storage, which use to store vm's qcow2 files,this ceph has 3 osd node +2. refer the link https://docs.ceph.com/en/quincy/rbd/libvirt/ create a ceph user :client.libvirt +3. import a exists qcow2 file into ceph libvit-pool, then start vm + +[root@ceph-1 ~]# ceph -s + cluster: + id: 3fbbf51f-88fd-4883-9f24-595bf853c5f2 + health: HEALTH_OK + + services: + mon: 1 daemons, quorum ceph-1 + mgr: ceph-1(active) + osd: 3 osds: 3 up, 3 in + + data: + pools: 1 pools, 128 pgs + objects: 940 objects, 3.6 GiB + usage: 31 GiB used, 209 GiB / 240 GiB avail + pgs: 128 active+clean + +[root@ceph-1 ~]#ceph auth ls +client.libvirt + key: AQD/XwFkq7kHMhAA1OmPtKPVno6gjmZleOevOA== + caps: [mon] allow r + caps: [osd] allow class-read object_prefix rbd_children, allow rwx pool=libvirt-pool + +[root@ceph-client ceph]# cat ceph.conf +[global] +fsid = 3fbbf51f-88fd-4883-9f24-595bf853c5f2 +mon_initial_members = ceph-1 +mon_host = 172.24.193.62 +auth_cluster_required = cephx +auth_service_required = cephx +auth_client_required = cephx + +osd_pool_default_size = 2 +[root@ceph-client ceph]# + +[root@ceph-client ceph]# virsh start c7_ceph +Domain c7_ceph started + +[root@ceph-client ceph]# +[root@ceph-client ceph]# virsh list --all + Id Name State +---------------------------------------------------- + 19 c7_ceph running + + + <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator> + <disk type='network' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <auth username='libvirt'> + <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/> + </auth> + <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2'> + <host name='172.24.193.62' port='6789'/> + <host name='172.24.193.63' port='6789'/> + <host name='172.24.193.64' port='6789'/> + </source> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </disk> + +======================== +[root@ceph-client ceph]# cat /run/libvirt/qemu/c7_ceph.xml + + +<domstatus state='running' reason='booted' pid='57437'> + <monitor path='/var/lib/libvirt/qemu/domain-19-c7_ceph/monitor.sock' json='1' type='unix'/> + <namespaces> + <mount/> + </namespaces> + <vcpus> + <vcpu id='0' pid='57487'/> + <vcpu id='1' pid='57488'/> + </vcpus> + <qemuCaps> + <flag name='kvm'/> + <flag name='no-hpet'/> + <flag name='spice'/> + <flag name='boot-index'/> + <flag name='hda-duplex'/> + <flag name='ccid-emulated'/> + <flag name='ccid-passthru'/> + <flag name='virtio-tx-alg'/> + <flag name='virtio-blk-pci.ioeventfd'/> + <flag name='sga'/> + <flag name='virtio-blk-pci.event_idx'/> + <flag name='virtio-net-pci.event_idx'/> + <flag name='piix3-usb-uhci'/> + <flag name='piix4-usb-uhci'/> + <flag name='usb-ehci'/> + <flag name='ich9-usb-ehci1'/> + <flag name='vt82c686b-usb-uhci'/> + <flag name='pci-ohci'/> + <flag name='usb-redir'/> + <flag name='usb-hub'/> + <flag name='ich9-ahci'/> + <flag name='no-acpi'/> + <flag name='virtio-blk-pci.scsi'/> + <flag name='scsi-disk.channel'/> + <flag name='scsi-block'/> + <flag name='transaction'/> + <flag name='block-job-async'/> + <flag name='scsi-cd'/> + <flag name='ide-cd'/> + <flag name='hda-micro'/> + <flag name='dump-guest-memory'/> + <flag name='nec-usb-xhci'/> + <flag name='balloon-event'/> + <flag name='lsi'/> + <flag name='virtio-scsi-pci'/> + <flag name='blockio'/> + <flag name='disable-s3'/> + <flag name='disable-s4'/> + <flag name='usb-redir.filter'/> + <flag name='ide-drive.wwn'/> + <flag name='scsi-disk.wwn'/> + <flag name='seccomp-sandbox'/> + <flag name='reboot-timeout'/> + <flag name='seamless-migration'/> + <flag name='block-commit'/> + <flag name='vnc'/> + <flag name='drive-mirror'/> + <flag name='usb-redir.bootindex'/> + <flag name='usb-host.bootindex'/> + <flag name='blockdev-snapshot-sync'/> + <flag name='qxl'/> + <flag name='VGA'/> + <flag name='cirrus-vga'/> + <flag name='vmware-svga'/> + <flag name='device-video-primary'/> + <flag name='usb-serial'/> + <flag name='usb-net'/> + <flag name='add-fd'/> + <flag name='nbd-server'/> + <flag name='virtio-rng'/> + <flag name='rng-random'/> + <flag name='rng-egd'/> + <flag name='megasas'/> + <flag name='tpm-passthrough'/> + <flag name='tpm-tis'/> + <flag name='pci-bridge'/> + <flag name='vfio-pci'/> + <flag name='vfio-pci.bootindex'/> + <flag name='scsi-generic'/> + <flag name='scsi-generic.bootindex'/> + <flag name='mem-merge'/> + <flag name='vnc-websocket'/> + <flag name='drive-discard'/> + <flag name='mlock'/> + <flag name='device-del-event'/> + <flag name='dmi-to-pci-bridge'/> + <flag name='i440fx-pci-hole64-size'/> + <flag name='q35-pci-hole64-size'/> + <flag name='usb-storage'/> + <flag name='usb-storage.removable'/> + <flag name='ich9-intel-hda'/> + <flag name='kvm-pit-lost-tick-policy'/> + <flag name='boot-strict'/> + <flag name='pvpanic'/> + <flag name='spice-file-xfer-disable'/> + <flag name='spiceport'/> + <flag name='usb-kbd'/> + <flag name='msg-timestamp'/> + <flag name='active-commit'/> + <flag name='change-backing-file'/> + <flag name='memory-backend-ram'/> + <flag name='numa'/> + <flag name='memory-backend-file'/> + <flag name='usb-audio'/> + <flag name='rtc-reset-reinjection'/> + <flag name='splash-timeout'/> + <flag name='iothread'/> + <flag name='migrate-rdma'/> + <flag name='ivshmem'/> + <flag name='drive-iotune-max'/> + <flag name='VGA.vgamem_mb'/> + <flag name='vmware-svga.vgamem_mb'/> + <flag name='qxl.vgamem_mb'/> + <flag name='pc-dimm'/> + <flag name='machine-vmport-opt'/> + <flag name='aes-key-wrap'/> + <flag name='dea-key-wrap'/> + <flag name='pci-serial'/> + <flag name='vhost-user-multiqueue'/> + <flag name='migration-event'/> + <flag name='ioh3420'/> + <flag name='x3130-upstream'/> + <flag name='xio3130-downstream'/> + <flag name='rtl8139'/> + <flag name='e1000'/> + <flag name='virtio-net'/> + <flag name='gic-version'/> + <flag name='incoming-defer'/> + <flag name='virtio-gpu'/> + <flag name='virtio-keyboard'/> + <flag name='virtio-mouse'/> + <flag name='virtio-tablet'/> + <flag name='virtio-input-host'/> + <flag name='chardev-file-append'/> + <flag name='ich9-disable-s3'/> + <flag name='ich9-disable-s4'/> + <flag name='vserport-change-event'/> + <flag name='virtio-balloon-pci.deflate-on-oom'/> + <flag name='mptsas1068'/> + <flag name='qxl.vram64_size_mb'/> + <flag name='chardev-logfile'/> + <flag name='debug-threads'/> + <flag name='secret'/> + <flag name='pxb'/> + <flag name='pxb-pcie'/> + <flag name='device-tray-moved-event'/> + <flag name='nec-usb-xhci-ports'/> + <flag name='virtio-scsi-pci.iothread'/> + <flag name='name-guest'/> + <flag name='qxl.max_outputs'/> + <flag name='spice-unix'/> + <flag name='drive-detect-zeroes'/> + <flag name='tls-creds-x509'/> + <flag name='intel-iommu'/> + <flag name='smm'/> + <flag name='virtio-pci-disable-legacy'/> + <flag name='query-hotpluggable-cpus'/> + <flag name='virtio-net.rx_queue_size'/> + <flag name='virtio-vga'/> + <flag name='drive-iotune-max-length'/> + <flag name='ivshmem-plain'/> + <flag name='ivshmem-doorbell'/> + <flag name='query-qmp-schema'/> + <flag name='gluster.debug_level'/> + <flag name='drive-iotune-group'/> + <flag name='query-cpu-model-expansion'/> + <flag name='virtio-net.host_mtu'/> + <flag name='nvdimm'/> + <flag name='pcie-root-port'/> + <flag name='query-cpu-definitions'/> + <flag name='block-write-threshold'/> + <flag name='query-named-block-nodes'/> + <flag name='cpu-cache'/> + <flag name='qemu-xhci'/> + <flag name='kernel-irqchip'/> + <flag name='kernel-irqchip.split'/> + <flag name='intel-iommu.intremap'/> + <flag name='intel-iommu.caching-mode'/> + <flag name='intel-iommu.eim'/> + <flag name='intel-iommu.device-iotlb'/> + <flag name='virtio.iommu_platform'/> + <flag name='virtio.ats'/> + <flag name='loadparm'/> + <flag name='vnc-multi-servers'/> + <flag name='virtio-net.tx_queue_size'/> + <flag name='chardev-reconnect'/> + <flag name='virtio-gpu.max_outputs'/> + <flag name='vxhs'/> + <flag name='virtio-blk.num-queues'/> + <flag name='vmcoreinfo'/> + <flag name='numa.dist'/> + <flag name='disk-share-rw'/> + <flag name='iscsi.password-secret'/> + <flag name='isa-serial'/> + <flag name='dump-completed'/> + <flag name='qcow2-luks'/> + <flag name='pcie-pci-bridge'/> + <flag name='seccomp-blacklist'/> + <flag name='query-cpus-fast'/> + <flag name='disk-write-cache'/> + <flag name='nbd-tls'/> + <flag name='tpm-crb'/> + <flag name='pr-manager-helper'/> + <flag name='qom-list-properties'/> + <flag name='memory-backend-file.discard-data'/> + <flag name='sdl-gl'/> + <flag name='screendump_device'/> + <flag name='hda-output'/> + <flag name='blockdev-del'/> + <flag name='vmgenid'/> + <flag name='vhost-vsock'/> + <flag name='chardev-fd-pass'/> + <flag name='tpm-emulator'/> + <flag name='mch'/> + <flag name='mch.extended-tseg-mbytes'/> + <flag name='usb-storage.werror'/> + <flag name='egl-headless'/> + <flag name='vfio-pci.display'/> + </qemuCaps> + <devices> + <device alias='rng0'/> + <device alias='virtio-disk0'/> + <device alias='virtio-serial0'/> + <device alias='video0'/> + <device alias='serial0'/> + <device alias='balloon0'/> + <device alias='channel0'/> + <device alias='net0'/> + <device alias='input0'/> + <device alias='scsi0'/> + <device alias='usb'/> + </devices> + <libDir path='/var/lib/libvirt/qemu/domain-19-c7_ceph'/> + <channelTargetDir path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph'/> + <cpu mode='custom' match='exact' check='partial'> + <model fallback='forbid'>Broadwell</model> + </cpu> + <chardevStdioLogd/> + <allowReboot value='yes'/> + <blockjobs active='no'/> + <domain type='kvm' id='19'> + <name>c7_ceph</name> + <uuid>ff08671e-824c-4939-80ec-602235c0662e</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Broadwell</model> + <feature policy='require' name='vme'/> + <feature policy='require' name='f16c'/> + <feature policy='require' name='rdrand'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + <feature policy='disable' name='erms'/> + <feature policy='require' name='xsaveopt'/> + <feature policy='require' name='abm'/> + </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>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator> + <disk type='network' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <auth username='libvirt'> + <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/> + </auth> + <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2' tlsFromConfig='0'> + <host name='172.24.193.62' port='6789'/> + <host name='172.24.193.63' port='6789'/> + <host name='172.24.193.64' port='6789'/> + <privateData> + <objects> + <secret type='auth' alias='virtio-disk0-secret0'/> + </objects> + </privateData> + </source> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' 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='0x04' 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='0x04' 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='0x04' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='scsi' index='0' model='lsilogic'> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:2e:e1:1f'/> + <source bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/2'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <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-19-c7_ceph/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'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0' fromConfig='0' autoGenerated='no'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </rng> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c99,c659</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c99,c659</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> + </domain> +</domstatus> +[root@ceph-client ceph]# + +/usr/local/qemu-3.0/bin/qemu-system-x86_64 which is build by qemu-3.0 source code , first i build qemu-3.0 source with --enable-rbd , +later i rebuild qemu-3.0 source with more config paramter from centos7-2009 qemu, those config paramter from qemu-kvm-1.5.3-175.el7.src.rpm ,which has those paramters: +# QEMU configure log Fri Mar 3 18:22:31 CST 2023 +# Configured with: './configure' '--prefix=/usr' '--libdir=/usr/lib64' '--sysconfdir=/etc' '--interp-prefix=/usr/qemu-%M' '--audio-drv-list=pa,alsa' '--with-confsuffix=/qemu-kvm' '--localstatedir=/var' '--libexecdir=/usr/libexec' '--wit +h-pkgversion=qemu-kvm-1.5.3-175.el7' '--disable-strip' '--disable-qom-cast-debug' '--extra-ldflags=-Wl,--build-id -pie -Wl,-z,relro -Wl,-z,now' '--extra-cflags=-O2 -g -pipe -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer +-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIE -DPIE' '--enable-trace-backend=dtrace' '--enable-werror' '--disable-xen' '--disable-virtfs' '--enable-kvm' '--enable-libusb' '--enable-spice' '--enable-seccomp' '--disable-fdt' '-- +enable-docs' '--disable-sdl' '--disable-debug-tcg' '--disable-sparse' '--disable-brlapi' '--disable-bluez' '--disable-vde' '--disable-curses' '--enable-curl' '--enable-libssh2' '--enable-vnc-tls' '--enable-vnc-sasl' '--enable-linux-aio' + '--enable-smartcard-nss' '--enable-lzo' '--enable-snappy' '--enable-usb-redir' '--enable-vnc-png' '--disable-vnc-jpeg' '--enable-vnc-ws' '--enable-uuid' '--disable-vhost-scsi' '--disable-guest-agent' '--disable-live-block-ops' '--disab +le-live-block-migration' '--enable-rbd' '--enable-glusterfs' '--enable-tcmalloc' '--block-drv-rw-whitelist=qcow2,raw,file,host_device,blkdebug,nbd,iscsi,gluster,rbd' '--block-drv-ro-whitelist=vmdk,vhdx,vpc,ssh,https' '--iasl=/bin/false' + '--target-list=x86_64-softmmu' + + +, after rebuild the qemu-system-x86_64 : + +virsh start c7_ceph +[root@ceph-client ceph]# virsh list --all + Id Name State +---------------------------------------------------- + 19 c7_ceph running + +qemu still stuck at booting from hard disk... + + + +to my surprised if the libvirtd xml file if i replace /usr/local/qemu-3.0/bin/qemu-system-x86_64 with /usr/libexec/bin/qemu-kvm , then the vm +can start successfully . diff --git a/results/classifier/105/KVM/1545 b/results/classifier/105/KVM/1545 new file mode 100644 index 00000000..a478bd1a --- /dev/null +++ b/results/classifier/105/KVM/1545 @@ -0,0 +1,22 @@ +KVM: 0.990 +device: 0.797 +network: 0.733 +socket: 0.665 +graphic: 0.641 +vnc: 0.460 +boot: 0.449 +semantic: 0.422 +instruction: 0.305 +mistranslation: 0.171 +other: 0.139 +assembly: 0.025 + +SSL is out of date on website +Description of problem: +The Linux KVM website is running an out of date SSL certificate. +Steps to reproduce: +1. visit the website. https://www.linux-kvm.org/page/Main_Page +2. +3. +Additional information: + diff --git a/results/classifier/105/KVM/1547012 b/results/classifier/105/KVM/1547012 new file mode 100644 index 00000000..cb28c977 --- /dev/null +++ b/results/classifier/105/KVM/1547012 @@ -0,0 +1,53 @@ +KVM: 0.913 +vnc: 0.900 +device: 0.872 +other: 0.870 +semantic: 0.869 +mistranslation: 0.866 +assembly: 0.865 +graphic: 0.859 +socket: 0.859 +instruction: 0.859 +boot: 0.848 +network: 0.840 + +qemu instances crashes with certain spice clients + +It's possible to make qemu instances crash when using certain browsers connected as spice-clients. + +my environment: + +- OpenStack Kilo installed from ubuntu-cloud archive (qemu-system-x86 2.2+dfsg-5expubuntu9.6~cloud0) +- Using spice for web-console access + +How to reproduce: + +1. Start a VM on openstack +2. access the OpenStack dashboard using iceweasel 43.0.4 +3. Open the spice-console +4. Leave the console open for few minutes +5. The VM will crash on the hypervisor + +The content of qemu log-files for this particular VM: + +2016-02-18 07:25:23.655+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name instance-0000188f -S -machine pc-i440fx-utopic,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid cb04ff25-056f-4f82-a2e8-1fbb762bc29e -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2015.1.2,serial=00000000-0000-0000-0000-0cc47a45f5e8,uuid=cb04ff25-056f-4f82-a2e8-1fbb762bc29e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000188f.monitor,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 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=rbd:libvirt/cb04ff25-056f-4f82-a2e8-1fbb762bc29e_disk:id=cinder:key=AQBYmdBUCDq7IBAA/7tLevRjdF3Bo7522xkFqA==:auth_supported=cephx\;none:mon_host=xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789\;xxx.xxx.xxx.xxx\:6789,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=55,id=hostnet0,vhost=on,vhostfd=58 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:a4:74:3b,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/cb04ff25-056f-4f82-a2e8-1fbb762bc29e/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -chardev pty,id=charchannel0 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5929,addr=172.24.1.30,disable-ticketing,seamless-migration=on -k fr-ch -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +char device redirected to /dev/pts/64 (label charserial1) +char device redirected to /dev/pts/65 (label charchannel0) +main_channel_link: add main channel client +main_channel_handle_parsed: net test: latency 44.136000 ms, bitrate 157538461538 bps (150240.384615 Mbps) +inputs_connect: inputs channel client create +red_dispatcher_set_cursor_peer: +((null):18188): SpiceWorker-CRITICAL **: red_worker.c:1629:common_alloc_recv_buf: unexpected message size 214862 (max is 1024) +2016-02-18 07:30:47.008+0000: shutting down + +It's funny because this error only occurs with certain browser versions, in my case with Iceweasel 43.0.4 and 44. 0 but it works well with Chrome 48.0.256482 and Firefox 44.0.2. + +Marking this a potential security issue as it could maybe lead to a denial-of-service if a user sends crafted packets. + +Added a network trace obtained on the computenode hosting the VM that I made crash. + +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/105/KVM/1553999 b/results/classifier/105/KVM/1553999 new file mode 100644 index 00000000..782f076a --- /dev/null +++ b/results/classifier/105/KVM/1553999 @@ -0,0 +1,40 @@ +KVM: 0.971 +graphic: 0.839 +device: 0.818 +instruction: 0.807 +semantic: 0.803 +mistranslation: 0.787 +other: 0.787 +boot: 0.597 +network: 0.571 +socket: 0.546 +vnc: 0.516 +assembly: 0.227 + +OpenGL support is disabled + +$ qemu-system-x86_64 -enable-kvm -display sdl,gl=on -vga qxl +SDL1 display code has no opengl support. +Please recompile qemu with SDL2, using +./configure --enable-sdl --with-sdlabi=2.0 +qemu-system-x86_64: OpenGL support is disabled + + +Can you please recompile qemu with support for opengl. The -display mode allows for opengl support. + +This feature allows for the guest OS to have opengl 2 support, that is require for several 3d applications. +It also opens the way for supporting acceleration on windows and Linux guest systems. + +Since you're talking about a pre-compiled binary, I assume you wanted to open this bug against Ubuntu's QEMU package, not against the QEMU project? + +Looks like that this bug is duplicate of https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1540692 + +Isn't it? + +Status changed to 'Confirmed' because the bug affects multiple users. + +Opengl in general as requested was enabled and backported up to Bionic (18.04). + +There are several usability enhancements to use that with either mdev passthrough and virtgl which I work on upstream and are going into Disco (19.04). + + diff --git a/results/classifier/105/KVM/1557057 b/results/classifier/105/KVM/1557057 new file mode 100644 index 00000000..85ae175c --- /dev/null +++ b/results/classifier/105/KVM/1557057 @@ -0,0 +1,91 @@ +KVM: 0.861 +device: 0.811 +vnc: 0.784 +boot: 0.736 +other: 0.725 +mistranslation: 0.648 +instruction: 0.646 +graphic: 0.633 +semantic: 0.630 +network: 0.621 +socket: 0.619 +assembly: 0.608 + +Windows 10 guest under qemu cannot wake up from S3 using rtc wake with -no_hpet + +Problem : Windows 10 guest cannot wake up from S3 using rtc wake + +Steps to reproduce. + +1. Boot Windows 10 Guest VM. +2. Create scheduled task (using Task Scheduler) to +5 minutes time from current time to run notepad and enabling "Wake the computer to run this task" option +3. Click Start->Power ->Sleep +4. Guest VM enters suspend mode( screen is black) +5. Wait 10 minutes - nothing happens +6. Press key in spicy window +7. VM resumes + +Expected behavior - VM should wake after 5 minutes in step 5. + +More information: +#uname -a +Linux vm-host 4.4.3-300.fc23.x86_64 #1 SMP Fri Feb 26 18:45:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux + +# /usr/local/bin/qemu-system-x86_64 --version +QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard + + +-----------------QEMU guest config--------------------- +OPTS="$OPTS -enable-kvm " +OPTS="$OPTS -name win10_35" +#OPTS="$OPTS -bios seabios/out/bios.bin" +OPTS="$OPTS -machine pc-q35-2.4,accel=kvm,usb=off,vmport=off" +OPTS="$OPTS -cpu Broadwell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff" +OPTS="$OPTS -m 4096" +OPTS="$OPTS -realtime mlock=off" +OPTS="$OPTS -smp 2,sockets=2,cores=1,threads=1" +OPTS="$OPTS -uuid e09cbfe5-9016-40b0-a027-62e0d2ef0ba1" +OPTS="$OPTS -no-user-config" +OPTS="$OPTS -nodefaults " +OPTS="$OPTS -rtc base=localtime,driftfix=slew" +OPTS="$OPTS -global kvm-pit.lost_tick_policy=discard" +OPTS="$OPTS -no-hpet" +OPTS="$OPTS -no-shutdown" +OPTS="$OPTS -global ICH9-LPC.disable_s3=0" +OPTS="$OPTS -global ICH9-LPC.disable_s4=0" +OPTS="$OPTS -boot order=c,menu=on,strict=on" +OPTS="$OPTS -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e" +OPTS="$OPTS -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1" +OPTS="$OPTS -device ich9-usb-ehci1,id=usb,bus=pci.2,addr=0x3.0x7" +OPTS="$OPTS -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.2,multifunction=on,addr=0x3" +OPTS="$OPTS -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.2,addr=0x3.0x1" +OPTS="$OPTS -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.2,addr=0x3.0x2" +OPTS="$OPTS -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4" +OPTS="$OPTS -drive file=/var/lib/images/win10-run2.qcow2,format=qcow2,if=none,id=drive-sata0-0-0,cache=none" +OPTS="$OPTS -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0" +OPTS="$OPTS -drive file=/var/lib/images/diskd.vhd,format=vpc,if=none,id=drive-sata0-0-1" +OPTS="$OPTS -device ide-hd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1" +OPTS="$OPTS -drive file=virtio-win.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-2,readonly=on" +OPTS="$OPTS -device ide-cd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2 " +OPTS="$OPTS -chardev pty,id=charserial0" +OPTS="$OPTS -device isa-serial,chardev=charserial0,id=serial0" +OPTS="$OPTS -chardev spicevmc,id=charchannel0,name=vdagent" +OPTS="$OPTS -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0" +OPTS="$OPTS -device usb-tablet,id=input0" +OPTS="$OPTS -spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on" +OPTS="$OPTS -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x1" +OPTS="$OPTS -device intel-hda,id=sound0,bus=pci.2,addr=0x2" +OPTS="$OPTS -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0" +OPTS="$OPTS -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5" +OPTS="$OPTS -msg timestamp=on" +OPTS="$OPTS -monitor stdio" +#OPTS="$OPTS -qmp stdio" +#OPTS="$OPTS -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios" + +/usr/local/bin/qemu-system-x86_64 $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/105/KVM/1559 b/results/classifier/105/KVM/1559 new file mode 100644 index 00000000..d9d25afe --- /dev/null +++ b/results/classifier/105/KVM/1559 @@ -0,0 +1,20 @@ +KVM: 0.995 +boot: 0.981 +graphic: 0.863 +device: 0.838 +mistranslation: 0.680 +semantic: 0.675 +instruction: 0.610 +other: 0.529 +vnc: 0.288 +socket: 0.128 +assembly: 0.055 +network: 0.048 + +7.2 (regression?): ppc64 KVM-HV hangs during boot +Description of problem: +qemu 7.2.0 hangs at " * Mounting ZFS filesystem(s) ..." whereas 7.1.0 would fully boot. + +Without -smp, sometimes gets further and hangs later on at " * Seeding random number generator ..." +Additional information: +7.1.0 used to work before upgrading to 7.2.0, but would hang randomly after booting (usually during my benchmark). Not sure if related. Unfortunately, after downgrading back to 7.1.0, it also now hangs the same way as 7.2.0 does. diff --git a/results/classifier/105/KVM/1565 b/results/classifier/105/KVM/1565 new file mode 100644 index 00000000..f2b2def7 --- /dev/null +++ b/results/classifier/105/KVM/1565 @@ -0,0 +1,47 @@ +KVM: 0.910 +device: 0.793 +graphic: 0.722 +instruction: 0.680 +network: 0.613 +vnc: 0.596 +semantic: 0.590 +socket: 0.568 +other: 0.457 +boot: 0.423 +mistranslation: 0.201 +assembly: 0.174 + +s390x TCG migration failure +Description of problem: +We're seeing failures running s390x migration kvm-unit-tests tests with TCG. + +Some initial findings: + +What seems to be happening is that after migration a control block header accessed by the test code is all zeros which causes an unexpected exception. + +I did a bisection which points to c8df4a7aef ("migration: Split save_live_pending() into state_pending_*") as the culprit. +The migration issue persists after applying the fix e264705012 ("migration: I messed state_pending_exact/estimate") on top of c8df4a7aef. + +Applying + +``` +diff --git a/migration/ram.c b/migration/ram.c +index 56ff9cd29d..2dc546cf28 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -3437,7 +3437,7 @@ static void ram_state_pending_exact(void *opaque, uint64_t max_size, + + uint64_t remaining_size = rs->migration_dirty_pages * TARGET_PAGE_SIZE; + +- if (!migration_in_postcopy()) { ++ if (!migration_in_postcopy() && remaining_size < max_size) { + qemu_mutex_lock_iothread(); + WITH_RCU_READ_LOCK_GUARD() { + migration_bitmap_sync_precopy(rs); +``` +on top fixes or hides the issue. (The comparison was removed by c8df4a7aef.) + +I arrived at this by experimentation, I haven't looked into why this makes a difference. +Steps to reproduce: +1. Run ACCEL=tcg ./run_tests.sh migration-skey-sequential with current QEMU master +2. Repeat until the test fails (doesn't happen every time, but still easy to reproduce) diff --git a/results/classifier/105/KVM/1570 b/results/classifier/105/KVM/1570 new file mode 100644 index 00000000..3492812d --- /dev/null +++ b/results/classifier/105/KVM/1570 @@ -0,0 +1,76 @@ +KVM: 0.794 +other: 0.772 +vnc: 0.758 +boot: 0.744 +device: 0.718 +graphic: 0.716 +mistranslation: 0.700 +assembly: 0.673 +instruction: 0.652 +socket: 0.630 +network: 0.626 +semantic: 0.593 + +Incorrect memory handling when booting redox +Description of problem: +During the boot of redox, I regularly get one of two errors when reading the HPET at base address `0xfed00000`: +- Incorrect translation from virtual address `0xffff8000fed00108` to random physical addresses, e.g. `0xfec00108` +- Invalid read at addr 0x0, size 8, region 'hpet', reason: invalid size (min:4 max:4) +Steps to reproduce: +1. Build the server version of the redox OS as per [the instructions](https://doc.redox-os.org/book/ch02-05-building-redox.html). +2. Run the qemu command line with multiple CPUs. The more CPUs the easier it is to reproduce. +3. The problem will manifest itself as a divide by zero error. See the corresponding [redox bug report](https://gitlab.redox-os.org/redox-os/kernel/-/issues/116). +Additional information: +The best evidence I have is a debug line I added to qemu before [the memory_region_dispatch_read line](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L1375): + +``` +if ((mr_offset & 0x1ff) == 0x108) fprintf(stderr, "cputlb io_readx cpu %d addr=%llx mr_offset=%llx mr=%p mr->addr=%llx\n", current_cpu->cpu_index, addr, mr_offset, mr, mr->addr); +r = memory_region_dispatch_read(mr, mr_offset, &val, op, full->attrs); +``` + +That logs: + +``` +cputlb io_readx cpu 0 addr=ffff8000fed00108 mr_offset=108 mr=0x7fefb60d5720 mr->addr=fec00000 +``` + +The expected physical address is `0xfed00000` instead of `0xfec00000`. + +A more extensive log is this one: +``` +55027@1680283224.671665:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f0 value 0x949707cc size 4 name 'hpet' <- ok +55027@1680283224.671681:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f4 value 0x0 size 4 name 'hpet' <- ok +tlb_set_page_full: vaddr=0000000000474000 paddr=0x000000000536f000 prot=5 idx=1 +... +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +... +55027@1680283224.671951:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00108 value 0x0 size 4 name 'ioapic' <- wrong +55027@1680283224.671958:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec0010c value 0x0 size 4 name 'ioapic' +55027@1680283224.671967:memory_region_ops_write cpu 2 mr 0x7f994d808d30 addr 0xcf8 value 0x8000fa80 size 4 name 'pci-conf-idx' +55027@1680283224.671986:memory_region_ops_read cpu 2 mr 0x7f994d808e40 addr 0xcfc value 0x80a805 size 4 name 'pci-conf-data' +55027@1680283224.672001:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00000 value 0x0 size 4 name 'ioapic' <- wrong +55027@1680283224.672010:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00004 value 0x0 size 4 name 'ioapic' +``` + +Some observations +- ~I seem to be the only one having this issue. Perhaps because I am the only one developing on MacOS. Maybe it's because I'm running an older intel mac.~. I managed to reproduce this on a Asus vivobook running linux +- The redox OS [reads the HPET](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_64/time.rs#L11) at addresses `0xf4`, `0x108`, `0x00` in that order. If I change the order to `0x00`, `0xf4`, `0x108`, the problem goes away. +- Even if I work around the problem by changing the order of the reads, the OS still randomly crashes. This could be related, but I can only speculate on that right now. +- Increasing qemu debug logging tends to push the problem to the 4vs8 size problem instead of the incorrect address one. The more logging, the more difficult it is to reproduce. +- I tried to bisect the issue and found I could only reproduce it after qemu version 5.2. However, the mac build broke during this process so I could not find the causal commit. Between 5.1 and 5.2 the performance is greatly increased though and I suspect whatever changed there caused the issue. +- I can't reproduce the problem with -smp 1 +- I have seen qemu segfault occasionally, but I didn't look further into it and I don't know if it's related to this issue. +- I have attempted to rule out a bug in redox. I am fairly certain nothing strange is going on there, but I can't say for sure. +- When I trigger the incorrect address bug, I mostly get a base address of `0xfec00000` which is the IO APIC. However, I do occasionally see other addresses too +- `info tlb` at the time of the fault shows + ``` + ffff8000fd3e6000: 00000000fd3e6000 X--DA---W + ffff8000fd3e7000: 00000000fd3e7000 X--DA---W + ffff8000fed00000: 00000000fed00000 X--DAC--W + ffff8000fee00000: 00000000fee00000 X--DA---W + fffffd8000000000: 0000000001e32000 XG-DA---W + fffffd8000001000: 0000000001e36000 XG-DA---W + ``` diff --git a/results/classifier/105/KVM/1574246 b/results/classifier/105/KVM/1574246 new file mode 100644 index 00000000..1c3f81c0 --- /dev/null +++ b/results/classifier/105/KVM/1574246 @@ -0,0 +1,93 @@ +KVM: 0.830 +semantic: 0.804 +vnc: 0.783 +instruction: 0.781 +graphic: 0.781 +socket: 0.768 +other: 0.764 +device: 0.764 +boot: 0.725 +assembly: 0.718 +network: 0.698 +mistranslation: 0.635 + +Drunken keyboard in go32v2 programs + +QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a while, though. + +Steps to reproduce: + +# Create a VM image, install DOS in it (doesn't matter which) and launch it. +# Launch a "bare DOS" DPMI host (not an operating system) in it; I tested with CWSDPMI and HDPMI32. +# Run a go32v2 program which reads keyboard input (say, the Lua interpreter: <http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/devel/lua.zip>; the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem unaffected). +# Quickly type in something random (e.g. alternate between hitting "p" and "q"), then optionally move the cursor left and right. +# Observe how some keystrokes are missed, and some are caught twice. + +The issue does NOT arise: +* on bare metal DOS, +* in VirtualBox, +* in Bochs with stock Plex86 BIOS, +* in Bochs with SeaBIOS, +* in DOSEMU, +* in DOSBox, +* in QEMU when the DPMI host is Windows 3.11/9x +so at this point I'm reasonably sure that it's the fault of either QEMU or SeaBIOS, and probably the former. The issue arises regardless of whether KVM is enabled. + +I compiled the latest git snapshot (tag: v2.6.0-rc4, calling itself 2.5.94; with GTK frontend) and could only half-reproduce the bug; keys do not longer "jam", but arrow keys are still captured twice. I woudn't make much of that difference; this bug seems very timing-sensitive. It could be that the GTK frontend adds sufficient latency to the interface to avoid triggering it. + +I enabled some debugging switches and recompiled both QEMU and the latest git snapshot of SeaBIOS (1.9.0-127; commit c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a). This is what I got when running programs affected by this bug: + +(key press) +[qemu ] ps2_queue(0xe0) +[qemu ] ps2_queue(0x4d) +(IRQ1) +[qemu ] KBD: kbd: read data=0xe0 ← (***) +[seabios] handle_09 +[qemu ] KBD: kbd: read status=0x1d +[qemu ] KBD: kbd: read data=0x4d +[seabios] i8042_command cmd=ae +[seabios] i8042_wait_write +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: write cmd=0xae +(IRQ1) +[qemu ] KBD: kbd: read data=0x4d ← (***) +[seabios] handle_09 +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: read data=0x4d +[seabios] i8042_command cmd=ae +[seabios] i8042_wait_write +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: write cmd=0xae + +Reads marked (***) do not appear when running unaffected programs. So it appears something is making reads from the keyboard controller before SeaBIOS has a chance to put scancodes in the ring buffer. And indeed: DJGPP libc installs a custom IRQ1 handler which does it to detect whether it should raise SIGINT in response to Ctrl+C; it can be found in the file src/libc/go32/exceptn.S in the djcrx package[1]. Free Pascal incorporates this handler into its RTL with almost no changes; it's found in rtl/go32v2/exceptn.as[2]. I also noticed I can reproduce this bug with Borland Pascal 7; lo and behold, the Turbo Vision library does something similar. + +SeaBIOS gets extra confused when I send some mouse events to QEMU (grab the mouse, move it around, ungrab); it reacts with a "ps2 keyboard irq but found mouse data?!" message and refuses to put keys in the ring buffer until the queue of mouse events becomes empty. + +That's the culprit, I think. It also explains why the bug doesn't appear under Windows; because port 0x60 reads from DPMI are simulated, they don't correspond to actual port 0x60 reads in the guest. I don't know what the fix ought be; documentation about the i8042 that I found is unclear about what real hardware does in this case. + +If I'm reading the code correctly, DOSEMU[3] (also the DOSEMU2 fork[4]), DOSBox[5], Bochs[6] and VirtualBox[7] keep one value to be read from 0x60 at until the next interrupt, avoiding the issue. + +[1] <http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/go32/exceptn.S?rev=1.7>; function ___djgpp_kbd_hdlr +[2] <http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/exceptn.as?revision=8210&view=co>; function ___djgpp_kbd_hdlr +[3] <https://sourceforge.net/p/dosemu/code/ci/8897222f8830e0bd2769935f611a0e5c3271bcb9/tree/src/plugin/kbd_unicode/serv_8042.c> +[4] <https://github.com/stsp/dosemu2/blob/69419c7a5430f0109f9df45b179d9b223b075550/src/plugin/kbd_unicode/serv_8042.c> +[5] <https://sourceforge.net/p/dosbox/code-0/3961/tree/dosbox/trunk/src/ints/bios_keyboard.cpp> +[6] <https://sourceforge.net/p/bochs/code/12853/tree/trunk/bochs/iodev/keyboard.cc> +[7] <https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Input/DevPS2.cpp?rev=60404> + + +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/105/KVM/1576347 b/results/classifier/105/KVM/1576347 new file mode 100644 index 00000000..6f30631f --- /dev/null +++ b/results/classifier/105/KVM/1576347 @@ -0,0 +1,303 @@ +KVM: 0.302 +other: 0.293 +vnc: 0.238 +device: 0.228 +network: 0.199 +boot: 0.185 +instruction: 0.180 +assembly: 0.177 +semantic: 0.162 +graphic: 0.160 +socket: 0.145 +mistranslation: 0.142 + +Only one NVMe device is usable in Windows (10) guest + +Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +QEMU version: 2.5.0 + +Kernel: 4.5.1 (Arch Linux) + +When there are two NVMe devices specified, only the second one will be usable in Windows. The following error is shown under "Device status" of the failed NVMe controller in Device Manager: + +"This device cannot start. (Code 10) + +The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect." + +The only thing seems suspicious to me is that the nvme emulation in qemu does not have WWN/EUI-64 set for the devices, though I have no idea at all whether that is mandatory: + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." + + + +You can see from the "SCSI name string" that the working NVMe device is the second one specified in the command. + + + + + +"if=virtio" (which similarly has one controller per drive and has each controller occupies a pci slot as the nvme emulation) works fine: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=virtio,format=qcow2,id=one -drive file=disks/two.img,if=virtio,format=qcow2,id=two + +Apparently it works fine in Linux though: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=Downloads/archlinux-2016.04.01-dual.iso,media=cdrom -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +I also tested WIndows installation ISOs instead as well. + +Windows 10 Enterprise 10586: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=Downloads/10586.0.151029-1700.TH2_RELEASE_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_EN-US.ISO,media=cdrom -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +Windows Server 2016 Technical Preview 5: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=Downloads/14300.1000.160324-1723.RS1_RELEASE_SVC_SERVER_OEMRET_X64FRE_EN-US.ISO,media=cdrom -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 + +Both of them shows only one of the NVMe drives. + +I also tested with two versions of OVMF, which are "18419" (https://github.com/tianocore/edk2/commit/ddd097e33f6e6829dc0413820e9971f3bf025f87) and "18455" (https://github.com/tianocore/edk2/commit/59844e126614fc8275aab083fafa5818cde0901c). + +On Thu, Apr 28, 2016 at 05:44:21PM -0000, Tom Yan wrote: + +CCing Keith Busch <email address hidden>, maintainer of QEMU NVMe. +Maybe he has an idea. + +> Public bug reported: +> +> Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m +> 4G -net bridge -net nic -full-screen -drive +> file=ovmf_x64.bin,format=raw,if=pflash -drive +> file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive +> file=disks/one.img,if=none,format=qcow2,id=one -drive +> file=disks/two.img,if=none,format=qcow2,id=two -device +> nvme,drive=one,serial=E86C3CFC43518D6F -device +> nvme,drive=two,serial=2BDAC262CF831698 +> +> QEMU version: 2.5.0 +> +> Kernel: 4.5.1 (Arch Linux) +> +> When there are two NVMe devices specified, only the second one will be +> usable in Windows. The following error is shown under "Device status" of +> the failed NVMe controller in Device Manager: +> +> "This device cannot start. (Code 10) +> +> The I/O device is configured incorrectly or the configuration parameters +> to the driver are incorrect." +> +> The only thing seems suspicious to me is that the nvme emulation in qemu +> does not have WWN/EUI-64 set for the devices, though I have no idea at +> all whether that is mandatory: +> +> "C:\Windows\system32>sg_vpd -i PD1 +> Device Identification VPD page: +> Addressed logical unit: +> designator type: SCSI name string, code set: UTF-8 +> SCSI name string: +> 8086QEMU NVMe Ctrl 00012BDAC262CF831698 +> +> C:\Windows\system32>sg_vpd -p sn PD1 +> Unit serial number VPD page: +> Unit serial number: 0000_0000_0000_0000." +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "Screenshot of Device Manager and the error." +> https://bugs.launchpad.net/bugs/1576347/+attachment/4650548/+files/01.PNG +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1576347 +> +> Title: +> Only one NVMe device is usable in Windows (10) guest +> +> Status in QEMU: +> New +> +> Bug description: +> Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m +> 4G -net bridge -net nic -full-screen -drive +> file=ovmf_x64.bin,format=raw,if=pflash -drive +> file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive +> file=disks/one.img,if=none,format=qcow2,id=one -drive +> file=disks/two.img,if=none,format=qcow2,id=two -device +> nvme,drive=one,serial=E86C3CFC43518D6F -device +> nvme,drive=two,serial=2BDAC262CF831698 +> +> QEMU version: 2.5.0 +> +> Kernel: 4.5.1 (Arch Linux) +> +> When there are two NVMe devices specified, only the second one will be +> usable in Windows. The following error is shown under "Device status" +> of the failed NVMe controller in Device Manager: +> +> "This device cannot start. (Code 10) +> +> The I/O device is configured incorrectly or the configuration +> parameters to the driver are incorrect." +> +> The only thing seems suspicious to me is that the nvme emulation in +> qemu does not have WWN/EUI-64 set for the devices, though I have no +> idea at all whether that is mandatory: +> +> "C:\Windows\system32>sg_vpd -i PD1 +> Device Identification VPD page: +> Addressed logical unit: +> designator type: SCSI name string, code set: UTF-8 +> SCSI name string: +> 8086QEMU NVMe Ctrl 00012BDAC262CF831698 +> +> C:\Windows\system32>sg_vpd -p sn PD1 +> Unit serial number VPD page: +> Unit serial number: 0000_0000_0000_0000." +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1576347/+subscriptions +> + + +On Fri, Apr 29, 2016 at 10:10:39AM +0100, Stefan Hajnoczi wrote: +> On Thu, Apr 28, 2016 at 05:44:21PM -0000, Tom Yan wrote: +> +> CCing Keith Busch <email address hidden>, maintainer of QEMU NVMe. +> Maybe he has an idea. + +Thanks for the report. Sounds like a Windows specific issue as I have no +problem with multiple nvme drives on my dev machines: + +[Host] +# uname -r +4.6.0-rc5+ + +# qemu-system-x86_64 --version +QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard + +# qemu-system-x86_64 -m 4096 -smp 4 -enable-kvm debian.img \ + -drive file=nvme.1.img,if=none,id=one -device nvme,drive=one,serial=foo \ + -drive file=nvme.2.img,if=none,id=two -device nvme,drive=two,serial=bar + +[Guest] +# uname -r +4.5.0 + +# ls /dev/nvme* +/dev/nvme0 /dev/nvme0n1 /dev/nvme1 /dev/nvme1n1 + +# nvme id-ctrl /dev/nvme0 | grep sn +sn : foo + +# nvme id-ctrl /dev/nvme1 | grep sn +sn : bar + +> > When there are two NVMe devices specified, only the second one will be +> > usable in Windows. The following error is shown under "Device status" of +> > the failed NVMe controller in Device Manager: +> > +> > "This device cannot start. (Code 10) +> > +> > The I/O device is configured incorrectly or the configuration parameters +> > to the driver are incorrect." +> > +> > The only thing seems suspicious to me is that the nvme emulation in qemu +> > does not have WWN/EUI-64 set for the devices, though I have no idea at +> > all whether that is mandatory: + +These are not mandatory. They were only introduced in the 1.1 and 1.2 versions +of the NVMe spec, though we only cared to emulate the 1.0 portions rather than +provide a full featured NVMe controller. + +That said, there needs to be care in the host OS to provide an appropriate +translation IF it is using a SCSI stack to talk to NVMe. Linux doesn't care, +but Windows does. + +> > "C:\Windows\system32>sg_vpd -i PD1 +> > Device Identification VPD page: +> > Addressed logical unit: +> > designator type: SCSI name string, code set: UTF-8 +> > SCSI name string: +> > 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +The above looks reasonable for your second controller that had serial +2BDAC262CF831698. + +> > C:\Windows\system32>sg_vpd -p sn PD1 +> > Unit serial number VPD page: +> > Unit serial number: 0000_0000_0000_0000." + +This doesn't look like a very good SCSI-NVMe translation and possibly +suspicious. But I don't know the first thing about windows; does it care about +unique unit serial numbers in order to surface a "SCSI" disk? + + +> > C:\Windows\system32>sg_vpd -p sn PD1 +> > Unit serial number VPD page: +> > Unit serial number: 0000_0000_0000_0000." + +I checked your serial number against the SNT refernce on nvmexpress.org and +it's definitely the wrong translation, so that has to be a guest OS driver bug +(Linux has the right translation if interested, but it's use is deprecated). + +I pinged some Windows comrades to see if a potential serial conflict prevents +both disks from surfacing. + +I'm surprised to see this bad translation as I know of folks successfully +testing multiple nvme drives in various versions of Windows with both the OFA +and Microsoft drivers. An emulated NVMe is no different than real h/w for +namespace identification from the host's perspective. + + +The problem still exists with qemu 2.7.0 and Windows 10 RS1. Btw I just did one more test, that I disable the working nvme controller in Device Manager to see if it makes the non-working one comes alive, but it does not, even if I reboot the virtual machine. + +For the record, the serial number translation is not fixed in RS1 either. + +Trying it on Windows 10 guest and QEMU 2.8.0 has the same issue. However, I noticed that: + Supplying 1 NVMe drive -> Win10 sees it. + Supplying 2 NVMe drives -> Win10 sees only one of them. + Supplying 3 NVMe drives -> Win10 sees only two of them. +So I still have been able to create a ReFS mirrored storage space with two NVMe disks under QEMU, I just had to pass three drives instead of two: + +qemu-system-x86_64 -enable-kvm <...> -drive file=/media/ssd/NVMe_drvA.qcow2,id=diskNVMeA,format=qcow2,if=none -drive file=/media/ssd/NVMe_drvB.qcow2,id=diskNVMeB,format=qcow2,if=none -drive file=/media/ssd/NVMe_drvC.qcow2,id=diskNVMeC,format=qcow2,if=none -device nvme,drive=diskNVMeA,serial=foo -device nvme,drive=diskNVMeB,serial=foo -device nvme,drive=diskNVMeC,serial=foo + +Hope this helps, +--Sergey + +Hello, I can also confirm that if you have a series of NVMe devices, at first when just the OVMF boot menu has loaded, using qemu with a -monitor and typing 'info pci', it appears that all are given valid bus addresses. + +However, once the Windows 10 x64 installer iso loads, it seems that every other NVMe device stays initialized correctly, but the ones in-between switch to a 0xfffff... bus address. So, for example, with 6 devices, numbers 1,3,5 will get initialized and recognized by the Windows installer, and 2,4,6 will not. Not sure if this clue helps identify this a qemu or Windows issue or not, but I thought it was worth noting. + +Also, I found that an alternative way to getting two or more NVMe devices successfully recognized by Windows is to use multiple root PCIe devices like so: + +qemu-system-x86_64 \ +-enable-kvm \ +-machine pc-q35-2.11,accel=kvm \ +-nodefaults \ +... +-device pcie-root-port,id=pcie_r0,bus=pcie.0,chassis=0,slot=0 \ +-device nvme,drive=disk0,serial=serial0,bus=pcie_r0 \ +-drive id=disk0,if=none,media=disk,cache=none,aio=native,format=raw,discard=unmap,file=/opt/os.raw \ +-device pcie-root-port,id=pcie_r1,bus=pcie.0,chassis=0,slot=1 \ +-device nvme,drive=disk1,serial=serial1,bus=pcie_r1 \ +-drive id=disk1,if=none,media=disk,cache=none,aio=native,format=raw,discard=unmap,file=/opt/data.raw \ + +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/105/KVM/1579645 b/results/classifier/105/KVM/1579645 new file mode 100644 index 00000000..fc18313f --- /dev/null +++ b/results/classifier/105/KVM/1579645 @@ -0,0 +1,31 @@ +KVM: 0.952 +graphic: 0.948 +boot: 0.912 +instruction: 0.772 +device: 0.732 +semantic: 0.716 +mistranslation: 0.651 +network: 0.639 +other: 0.623 +vnc: 0.491 +assembly: 0.468 +socket: 0.409 + + [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97" + +Environment: + +when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below: +"audio: Could no init “oss” audio driver.", +then login the guest and try run audio, no sound output. +Reproduce: +1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img] + xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure +2. it will show "audio: Could no init “oss” audio driver". +3. login in guest, it can detect audio device, but actually it is not working. + +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/105/KVM/1583 b/results/classifier/105/KVM/1583 new file mode 100644 index 00000000..f9080361 --- /dev/null +++ b/results/classifier/105/KVM/1583 @@ -0,0 +1,32 @@ +KVM: 0.996 +device: 0.949 +graphic: 0.927 +instruction: 0.805 +vnc: 0.722 +semantic: 0.683 +other: 0.673 +socket: 0.655 +boot: 0.639 +network: 0.627 +mistranslation: 0.358 +assembly: 0.201 + +SGX Device mapping is not listed into QEMU KVM +Description of problem: +I want to run SGX into QEMU VM, the vm is up and running but SGX device mappings are not listed there. I also looked in dmesg | grep sgx and it returned "There are zero epc section" + +I have upgraded the libvirt to 8.6.0 because of below issue +https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1982896 + +I tried with libvirt-8.0.0 but it did not help + +I have attached the xml, please let me know why sgx mappings are not showing inside VM +Steps to reproduce: +1. Create a Ubuntu 20.04 VM with SGX mapping +Additional information: +Please let me know if any other logs are required + + + + +[ubuntu20.04.xml](/uploads/2609abc31db08e04cc3e3dbf923cd8d7/ubuntu20.04.xml) diff --git a/results/classifier/105/KVM/1583775 b/results/classifier/105/KVM/1583775 new file mode 100644 index 00000000..2f6ce374 --- /dev/null +++ b/results/classifier/105/KVM/1583775 @@ -0,0 +1,52 @@ +KVM: 0.803 +other: 0.718 +mistranslation: 0.680 +device: 0.636 +graphic: 0.570 +socket: 0.533 +semantic: 0.524 +network: 0.509 +boot: 0.377 +assembly: 0.306 +instruction: 0.303 +vnc: 0.262 + +Feature Request: qemu 2.6.0 + +Qemu 2.6.0 just got released, and according to changelogs it has quite some enhancements... + +would it be possible to have someone who has a qemu ppa on launchpad to migrate this into his ppa? + +thanks in advance + +I'm testing a merge of it right now. + +On Thu, May 19, 2016 at 9:13 PM, Launchpad Bug Tracker +<email address hidden> wrote: +> You have been subscribed to a public bug: +> +> Qemu 2.6.0 just got released, and according to changelogs it has quite +> some enhancements... +> +> would it be possible to have someone who has a qemu ppa on launchpad to +> migrate this into his ppa? +> +> thanks in advance +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: kvm qemu spice vfio virtio +> -- +> Feature Request: qemu 2.6.0 +> https://bugs.launchpad.net/bugs/1583775 +> You received this bug notification because you are subscribed to QEMU. + + +thank you very much serge=) + +Hi; I'm going to close this because it isn't a bug in upstream QEMU (which only does source releases). + + diff --git a/results/classifier/105/KVM/1591628 b/results/classifier/105/KVM/1591628 new file mode 100644 index 00000000..9b9fb4a4 --- /dev/null +++ b/results/classifier/105/KVM/1591628 @@ -0,0 +1,193 @@ +KVM: 0.716 +mistranslation: 0.627 +semantic: 0.618 +device: 0.614 +vnc: 0.606 +other: 0.598 +network: 0.586 +instruction: 0.574 +boot: 0.563 +graphic: 0.527 +socket: 0.517 +assembly: 0.493 + +2.6.0 hangs linux vm using vfio for pci passthrough of graphics card + +Not a duplicate of my old bug 1488363 + +qemu version 2.5.1 works fine +qemu version 2.6.0 fails + +seabios 1.9.2-1 + +using kernel 4.5.5 with grsecurity + +I built using the arch packaging tools, but commented out all the patch code, so it should be vanilla. + +The problem is just that I start a Linux vm using either my radeon R7 260x or radeon HD 6770, and with qemu 2.6.0, it looks normal until after the grub menu, and then the screen looks broken (with mostly black, and some pixely junk spread horizontally in a few places on the screen... first we thought maybe the monitor died). I'm not sure if it's before or only at the moment where the screen resolution changes (I could check that or record it on request). Also, the VM is not pingable and does not respond to "system_powerdown" on qemu monitor. + +However, the same setup works fine with windows 8. And it works fine without graphics cards passed through. A usb controller passed through works fine too. + + +And then I ran a bisect... + + 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 is the first bad commit + commit 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 + Author: Alex Williamson <email address hidden> + Date: Thu Mar 10 09:39:08 2016 -0700 + + vfio/pci: Convert all MemoryRegion to dynamic alloc and consistent functions + + Match common vfio code with setup, exit, and finalize functions for + BAR, quirk, and VGA management. VGA is also changed to dynamic + allocation to match the other MemoryRegions. + + Signed-off-by: Alex Williamson <email address hidden> + + :040000 040000 0acfd49b6ecae780b6f52a34080ecec6b3ec3672 e0cfdadede08f553463c0b23931eda81107f41b8 M hw + +then confirm it by reverting that commit + git checkout v2.6.0 + git revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 + git mergetool -t kdiff3 + "select all from C", save + not sure if this is the right way to do this...but it compiles and works (bug fixed) + git commit -m "revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 resolve conflicts" + +And that 2.6.0 build with that one patch reverted works fine. + +And here's the qemu command (missing \ at the end of the lines) + + +qemu-system-x86_64 + -enable-kvm + -M q35 + -m 3584 + -cpu host + -boot c + -smp 8,sockets=1,cores=8,threads=1 + -vga none + -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 + -device vfio-pci,host=05:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=/mnt/archive/software/vgarom/Sapphire.HD6770.1024/Sapphire.HD6770.1024.120105.rom + -device vfio-pci,host=00:13.0,bus=pcie.0 + -device vfio-pci,host=00:13.2,bus=pcie.0 + -usb + -device ahci,bus=pcie.0,id=ahci + -drive file=/dev/ssd/manjaro-a,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on + -drive file=/mnt/archive/software/manjaro/manjaro-net-0.8.12-openrc-x86_64.iso,id=isocd1,index=2,media=cdrom + -drive file=,id=isocd2,index=3,media=cdrom + -drive media=cdrom,id=cdrom,index=5,media=cdrom + -netdev type=tap,id=net0,ifname=tap-7a + -device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05 + -monitor stdio + -boot menu=on + -vnc :12 + + +I'm not able to reproduce. Testing with an HD8570 and the following commandline: + +/usr/local/bin/qemu-system-x86_64 -enable-kvm -M q35 -m 4G -cpu host -smp 8 -vga none -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 -device vfio-pci,host=2:00.0,bus=root.1,x-vga=on,addr=0.0 -usb -device ahci,bus=pcie.0,id=ahci -drive file=/mnt/ISOs/Fedora-Live-Cinnamon-x86_64-23-10.iso,id=iso,index=0,media=cdrom -net none -nographic -monitor stdio -boot menu=on -serial none -parallel none -device usb-host,hostbus=3,hostaddr=7 + +(where the passthrough usb device is composite mouse/kbd for a kvm) Same results with Fedora virt-preview provided qemu-kvm binary (qemu-system-x86-2.6.0-3.fc23.x86_64) + +Please try to reduce to the minimum commandline to reproduce, take a picture of the symptoms you're describing, and if possible get a dmesg log from the guest. + +(changed your command with a different iso, and without the usb-host, and with a pci passthrough of a usb controller, and with a vgarom for my gpu otherwise I find it hangs if I repeatedly reboot a VM) + +If I try with your command with an iso it works. If I replace the iso with the VM's disk, it fails (see photo). + +I'm not sure what is special about the VM. I tried a grsecurity kernel 4.1.6, and vanilla kernel 3.18.35, which both hang. And I tried single user mode. I figured maybe it's something in grub. So I cleared out my grub.cfg other than memtest86+ (grub.cfg attached)... and it still fails, but this time it's a black screen except for the manjaro logo in the bottom right (attached). + + + + + + + +Attached is a 4.7 MB xz image of a 20 MB disk image that triggers the problem. It contains a grub2 (2.02~beta2) bootloader, /boot with memtest86+, and no rootfs. + +If I load that as is, it hangs. + +If I comment out the "load_video" line, it works. (memtest doesn't run properly, but auto-reboots, but that's not the issue) + + + +Ran as: + +# /usr/local/bin/qemu-system-x86_64 -enable-kvm -M q35 -m 4G -cpu host -smp 8 \ + -vga none -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 \ + -device vfio-pci,host=02:00.0,bus=root.1,x-vga=on,addr=0.0,romfile=/root/HD8570.rom \ + -device ahci,bus=pcie.0,id=ahci \ + -drive file=/root/qemutest2.img,id=iso,index=0,media=disk,format=raw \ + -net none -nographic -monitor stdio -serial none -parallel none + +Works fine, memtest86+ works fine too. Are you on an AMD or Intel host? Can you try with a recent, stock (non-grsecurity) kernel? Can you reproduce without the assigned USB devices? + +It's an AMD FX(tm)-8150 with a GA-990FXA-UD5 board bios version F11. I also tested without the usb controllers, such as with your suggested commands. And again below. + +root@peter:~ # uname -a +Linux peter 4.6.2-1-MANJARO #1 SMP PREEMPT Wed Jun 8 11:00:08 UTC 2016 x86_64 GNU/Linux + +root@peter:~ # cat /proc/cmdline +BOOT_IMAGE=/boot/vmlinuz-4.6-x86_64 root=UUID=dc395127-6336-448f-a950-137c100420c9 rw pcie_acs_override=downstream apparmor=1 security=apparmor vfio-pci.pci-ids=00:13.0,00:13.2,00:14.2,00:16.0,00:16.2,01:00.1,04:00.0,04:00.1,05:00.0,05:00.1 + +the vfio-pci.pci-ids=... is for a mkinitcpio hook I wrote that binds vfio-pci early so X has no chance to touch the GPUs and risk hanging the system; it runs before the radeon driver is loaded; it does 3 steps: unbind on each listed, then vfio-pci bind which annoyingly takes non-unique device:vendor rather than pci address, then unbind anything not listed to solve the non-unique problem (relevant since the host also has the same GPU device:vendor id, and usb controllers) + +and you can ignore the apparmor stuff since this stock kernel has no apparmor support + +Testing with my full command or your command, with minimal changes (pci id, path to romfile, my disk is lvm rather than file) +... + instead of a black screen/manjaro logo, I get a screen more like the first photo with colored pixel mess. + And a new error (that plus the non-black screen are possibly because I waited longer rather than changing the test): + + root@peter:~/kvm # qemu-system-x86_64 -enable-kvm -M q35 -m 4G -cpu host -smp 8 \ + > -vga none -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 \ + > -device vfio-pci,host=05:00.0,bus=root.1,x-vga=on,addr=0.0,romfile=/mnt/archive/software/vgarom/Sapphire.HD6770.1024/Sapphire.HD6770.1024.120105.rom \ + > -device ahci,bus=pcie.0,id=ahci \ + > -drive file=/dev/data/qemutest2,id=iso,index=0,media=disk,format=raw \ + > -net none -nographic -monitor stdio -serial none -parallel none + QEMU 2.6.0 monitor - type 'help' for more information + (qemu) KVM internal error. Suberror: 1 + emulation failure + EAX=b0000000 EBX=00000000 ECX=000f80f2 EDX=7f729950 + ESI=005a3c00 EDI=7feb82e0 EBP=0007fe1c ESP=0007fe14 + EIP=0000cd12 EFL=00000017 [----APC] CPL=0 II=0 A20=1 SMM=0 HLT=0 + ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] + SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT + TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy + GDT= 00008280 00000027 + IDT= 00000000 00000000 + CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 + DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 + DR6=00000000ffff0ff0 DR7=0000000000000400 + EFER=0000000000000000 + Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +and here's without the acs thing + vfio: No available IOMMU models + vfio: failed to setup container for group 20 + + ummm I though this worked in the past and this acs thing was only needed for my onboard sound to pass through correctly. Not sure what to do. + + If you want me to try another setting for pcie_acs_override=downstream, feel free to suggest. + + + +FYI I tried my grsec kernel (which also has some =m changed to =y so maybe I only forgot a modprobe command before) without acs_override=downstream which works with the revert build, and hangs without. + +Please test the patch in the link below and send your email address (privately if preferred) so I can provide proper attributes for Reported-by. Thanks. + +https://paste.fedoraproject.org/381971/46638926/ + +It works. :) Thanks a bunch. + +I tested linux it originally crashed with, plus the memtest86+ (still auto rebooted though), and no sign of a problem. + +Fix has been included in QEMU v2.7.0: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d3fc4fdc6857e33346e + diff --git a/results/classifier/105/KVM/1597 b/results/classifier/105/KVM/1597 new file mode 100644 index 00000000..e3a61717 --- /dev/null +++ b/results/classifier/105/KVM/1597 @@ -0,0 +1,69 @@ +KVM: 0.779 +boot: 0.707 +device: 0.700 +instruction: 0.615 +socket: 0.611 +semantic: 0.548 +graphic: 0.543 +vnc: 0.493 +assembly: 0.450 +mistranslation: 0.317 +other: 0.291 +network: 0.271 + +Intel Arc A-Series GPUs VFIO passthrough no video out +Description of problem: +Once the VM is booted, the screen goes blank. +Steps to reproduce: +1. Passthough any Intel Arc A (Alchemist) series video card. +2. Boot VM. +3. Screen goes blank. +Additional information: +I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I start the VM that issue presents itself. + + + +kernel command line: + +``` +amd_iommu=on iommu=pt rd.driver.pre=vfio-pci pci=realloc iommu=1 i915.force_probe=* + +``` + +startup script: + +``` +#!/bin/bash +# Helpful to read output when debugging +set -x + +# Load the config file with our environmental variables +source "/etc/libvirt/hooks/kvm.conf" +source "/etc/libvirt/hooks/vmPreBootSetup" + +cpuPerf + +# Stop your display manager. If you're on kde it'll be sddm.service. Gnome users should use 'killall gdm-x-session' instead +systemctl stop gdm.service + +# Unbind VTconsoles +echo 0 > /sys/class/vtconsole/vtcon0/bind +echo 0 > /sys/class/vtconsole/vtcon1/bind + +# Avoid a race condition by waiting a couple of seconds. This can be calibrated to be shorter or longer if required for your system +sleep 2 + +modprobe -r drm_buddy intel_gtt video drm_display_helper cec ttm i915 + +# Unbind the GPU from display driver +virsh nodedev-detach $VIRSH_GPU_VIDEO +virsh nodedev-detach $VIRSH_GPU_AUDIO + +# Load VFIO kernel module +modprobe vfio +modprobe vfio_pci +modprobe vfio_iommu_type1 + +sleep 5s ; systemctl restart connman.service + +``` diff --git a/results/classifier/105/KVM/1626596 b/results/classifier/105/KVM/1626596 new file mode 100644 index 00000000..6519e76b --- /dev/null +++ b/results/classifier/105/KVM/1626596 @@ -0,0 +1,36 @@ +KVM: 0.826 +graphic: 0.808 +vnc: 0.762 +device: 0.761 +network: 0.710 +instruction: 0.708 +mistranslation: 0.620 +other: 0.586 +semantic: 0.580 +socket: 0.514 +assembly: 0.471 +boot: 0.429 + +Lockup with vhost network + +After using Qemu in this configuration successfully for quite a while, I changed two things: +- moved the VM from a 8-core 4GHz host to a slower 2-core 1.6 Ghz machine +- upgraded qemu from 2.1 to 2.5 + +and almost immediately (in a couple hours) got hit with a vhost-related lockup. + +QEMU command line is: + +qemu-system-x86_64 -enable-kvm -daemonize -monitor unix:./monitor,server,nowait -cpu host -M q35 -balloon virtio -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd -drive if=none,id=hd,cache=writeback,aio=native,format=raw,file=xxxx.img,discard=unmap,detect-zeroes=unmap -device virtio-net-pci,netdev=net0,mac=xxxx -netdev tap,vhost=on,id=net0,script=xxxx.sh -usbdevice tablet -smp 2 -m 512 -vnc xxxx:yz + +VM was running fine, except no network traffic was passed from/to it. Shutting down the VM, it hung at "Will now halt." The QEMU process was unkillable, so the only choice was to sysrq-b the entire box. + +dmesg with sysrq-w attached. + + + +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/105/KVM/1626972 b/results/classifier/105/KVM/1626972 new file mode 100644 index 00000000..07ce6702 --- /dev/null +++ b/results/classifier/105/KVM/1626972 @@ -0,0 +1,3869 @@ +KVM: 0.571 +vnc: 0.495 +other: 0.474 +mistranslation: 0.438 +device: 0.260 +network: 0.230 +semantic: 0.216 +assembly: 0.214 +graphic: 0.214 +boot: 0.210 +socket: 0.200 +instruction: 0.189 + +QEMU memfd_create fallback mechanism change for security drivers + +And, when libvirt starts using apparmor, and creating apparmor profiles for every virtual machine created in the compute nodes, mitaka qemu (2.5 - and upstream also) uses a fallback mechanism for creating shared memory for live-migrations. This fall back mechanism, on kernels 3.13 - that don't have memfd_create() system-call, try to create files on /tmp/ directory and fails.. causing live-migration not to work. + +Trusty with kernel 3.13 + Mitaka with qemu 2.5 + apparmor capability = can't live migrate. + +From qemu 2.5, logic is on : + +void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, int *fd) +{ + if (memfd_create)... ### only works with HWE kernels + + else ### 3.13 kernels, gets blocked by apparmor + tmpdir = g_get_tmp_dir + ... + mfd = mkstemp(fname) +} + +And you can see the errors: + +From the host trying to send the virtual machine: + +2016-08-15 16:36:26.160 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Migration operation has aborted +2016-08-15 16:36:26.248 1974 ERROR nova.virt.libvirt.driver [req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 133ebc3585c041aebaead8c062cd6511 - - -] [instance: 2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Live Migration failure: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +From the host trying to receive the virtual machine: + +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.356794] type=1400 audit(1471289779.791:72): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12565 comm="apparmor_parser" +Aug 15 16:36:19 tkcompute01 kernel: [ 1194.357048] type=1400 audit(1471289779.791:73): apparmor="STATUS" operation="profile_load" profile="unconfined" name="qemu_bridge_helper" pid=12565 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.877027] type=1400 audit(1471289780.311:74): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.904407] type=1400 audit(1471289780.343:75): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=12613 comm="apparmor_parser" +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.973064] type=1400 audit(1471289780.407:76): apparmor="DENIED" operation="mknod" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/memfd-tNpKSj" pid=12625 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 ouid=107 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979871] type=1400 audit(1471289780.411:77): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 +Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979881] type=1400 audit(1471289780.411:78): apparmor="DENIED" operation="open" profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/var/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 + +When leaving libvirt without apparmor capabilities (thus not confining virtual machines on compute nodes, the live migration works as expected, so, clearly, apparmor is stepping into the live migration). I'm sure that virtual machines have to be confined and that this isn't the desired behaviour... + +Related: https://bugs.launchpad.net/nova/+bug/1613423 + +I came up with this patch for QEMU: + +http://paste.ubuntu.com/23217056/ + +I'm finishing libvirt patch so I can propose upstream QEMU already sure that libvirt will benefit from this change. Right after I'll propose libvirt upstream patch (changing vert-aa-helper logic). + +And later: + +Improved it a little bit: http://paste.ubuntu.com/23217333/ + +And fixed it: + +http://paste.ubuntu.com/23219599/ +(Probable the version to be suggested to upstream) + +Fixed it according to checkpatch.pl as stated in http://wiki.qemu.org/Contribute/SubmitAPatch. + +http://paste.ubuntu.com/23220104/ + +Will submit to mailing list after testing everything. + +Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +mechanism for systems not supporting memfd_create syscall (started +being supported since 3.17). + +Backporting memfd_create might not be accepted for distros relying +on older kernels. Nowadays there is no way for security driver +to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. + +It is more appropriate to include UUID and/or VM names in the +temporary filename, allowing security driver rules to be applied +while maintaining the required unpredictability with mkstemp. + +This change will allow libvirt to know exact memfd file to be created +for vhost log AND to create appropriate security rules to allow access +per instance (instead of a opened rule like <tmpdir>/memfd-*). + +Example of apparmor deny messages with this change: + +Per VM UUID (preferred, generated automatically by libvirt): + +kernel: [26632.154856] type=1400 audit(1474945148.633:78): apparmor= +"DENIED" operation="mknod" profile="libvirt-0b96011f-0dc0-44a3-92c3- +196de2efab6d" name="/tmp/memfd-0b96011f-0dc0-44a3-92c3-196de2efab6d- +qeHrBV" pid=75161 comm="qemu-system-x86" requested_mask="c" denied_ +mask="c" fsuid=107 ouid=107 + +Per VM name (if no UUID is specified): + +kernel: [26447.505653] type=1400 audit(1474944963.985:72): apparmor= +"DENIED" operation="mknod" profile="libvirt-00000000-0000-0000-0000- +000000000000" name="/tmp/memfd-instance-teste-osYpHh" pid=74648 +comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 +ouid=107 + +Signed-off-by: Rafael David Tinoco <email address hidden> +--- + util/memfd.c | 26 +++++++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +diff --git a/util/memfd.c b/util/memfd.c +index 4571d1a..4b715ac 100644 +--- a/util/memfd.c ++++ b/util/memfd.c +@@ -30,6 +30,9 @@ + #include <glib/gprintf.h> + + #include "qemu/memfd.h" ++#include "qmp-commands.h" ++#include "qemu-common.h" ++#include "sysemu/sysemu.h" + + #ifdef CONFIG_MEMFD + #include <sys/memfd.h> +@@ -94,11 +97,32 @@ void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, + return NULL; + } + } else { ++ int ret = 0; + const char *tmpdir = g_get_tmp_dir(); ++ UuidInfo *uinfo; ++ NameInfo *ninfo; + gchar *fname; + +- fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ uinfo = qmp_query_uuid(NULL); ++ ++ ret = strcmp(uinfo->UUID, UUID_NONE); ++ if (ret == 0) { ++ ninfo = qmp_query_name(NULL); ++ if (ninfo->has_name) { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ ninfo->name); ++ } else { ++ fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ } ++ qapi_free_NameInfo(ninfo); ++ } else { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ uinfo->UUID); ++ } ++ + mfd = mkstemp(fname); ++ ++ qapi_free_UuidInfo(uinfo); + unlink(fname); + g_free(fname); + +-- +2.9.3 + + + +Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +mechanism for systems not supporting memfd_create syscall (started +being supported since 3.17). + +Backporting memfd_create might not be accepted for distros relying +on older kernels. Nowadays there is no way for security driver +to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. + +It is more appropriate to include UUID and/or VM names in the +temporary filename, allowing security driver rules to be applied +while maintaining the required unpredictability with mkstemp. + +This change will allow libvirt to know exact memfd file to be created +for vhost log AND to create appropriate security rules to allow access +per instance (instead of a opened rule like <tmpdir>/memfd-*). + +Example of apparmor deny messages with this change: + +Per VM UUID (preferred, generated automatically by libvirt): + +kernel: [26632.154856] type=1400 audit(1474945148.633:78): apparmor= +"DENIED" operation="mknod" profile="libvirt-0b96011f-0dc0-44a3-92c3- +196de2efab6d" name="/tmp/memfd-0b96011f-0dc0-44a3-92c3-196de2efab6d- +qeHrBV" pid=75161 comm="qemu-system-x86" requested_mask="c" denied_ +mask="c" fsuid=107 ouid=107 + +Per VM name (if no UUID is specified): + +kernel: [26447.505653] type=1400 audit(1474944963.985:72): apparmor= +"DENIED" operation="mknod" profile="libvirt-00000000-0000-0000-0000- +000000000000" name="/tmp/memfd-instance-teste-osYpHh" pid=74648 +comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 +ouid=107 + +Signed-off-by: Rafael David Tinoco <email address hidden> +--- + util/memfd.c | 26 +++++++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +diff --git a/util/memfd.c b/util/memfd.c +index 4571d1a..4b715ac 100644 +--- a/util/memfd.c ++++ b/util/memfd.c +@@ -30,6 +30,9 @@ + #include <glib/gprintf.h> + + #include "qemu/memfd.h" ++#include "qmp-commands.h" ++#include "qemu-common.h" ++#include "sysemu/sysemu.h" + + #ifdef CONFIG_MEMFD + #include <sys/memfd.h> +@@ -94,11 +97,32 @@ void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, + return NULL; + } + } else { ++ int ret = 0; + const char *tmpdir = g_get_tmp_dir(); ++ UuidInfo *uinfo; ++ NameInfo *ninfo; + gchar *fname; + +- fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ uinfo = qmp_query_uuid(NULL); ++ ++ ret = strcmp(uinfo->UUID, UUID_NONE); ++ if (ret == 0) { ++ ninfo = qmp_query_name(NULL); ++ if (ninfo->has_name) { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ ninfo->name); ++ } else { ++ fname = g_strdup_printf("%s/memfd-XXXXXX", tmpdir); ++ } ++ qapi_free_NameInfo(ninfo); ++ } else { ++ fname = g_strdup_printf("%s/memfd-%s-XXXXXX", tmpdir, ++ uinfo->UUID); ++ } ++ + mfd = mkstemp(fname); ++ ++ qapi_free_UuidInfo(uinfo); + unlink(fname); + g_free(fname); + +-- +2.9.3 + + + +I'll follow to see if patch was accepted upstream: + +https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06191.html +https://<email address hidden>/msg400892.html + +On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +> mechanism for systems not supporting memfd_create syscall (started +> being supported since 3.17). + +This is really dubious code in general and IMHO should just +be reverted. + +We have a golden rule that any time QEMU needs to be able to +create a file on disk, then the path should be explicitly +provided as a command line argument so that mgmt apps can +control the location used. + +> Backporting memfd_create might not be accepted for distros relying +> on older kernels. Nowadays there is no way for security driver +> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> +> It is more appropriate to include UUID and/or VM names in the +> temporary filename, allowing security driver rules to be applied +> while maintaining the required unpredictability with mkstemp. + +We should not have QEMU creating unpredictabile filenames in the +first place - any filenames should be determined by libvirt +explicitly. + +> This change will allow libvirt to know exact memfd file to be created +> for vhost log AND to create appropriate security rules to allow access +> per instance (instead of a opened rule like <tmpdir>/memfd-*). + +Even with this change it is bad - we don't want driver backends +creating arbitrary files in the shared /tmp directory. + + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| +|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| + + + +> On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> +> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +>> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +>> mechanism for systems not supporting memfd_create syscall (started +>> being supported since 3.17). +> +> This is really dubious code in general and IMHO should just +> be reverted. + +There are numerous people relying on older kernels in openstack +deployments - sometimes with specific drivers (ovswitch, dpdk, +infiniband) holding kernel upgrades - but still in need of upgrading +userland (e.g. newer releases). Having a fallback mechanism seems +appropriate for those cases. + +> +> We have a golden rule that any time QEMU needs to be able to +> create a file on disk, then the path should be explicitly +> provided as a command line argument so that mgmt apps can +> control the location used. +> +>> Backporting memfd_create might not be accepted for distros relying +>> on older kernels. Nowadays there is no way for security driver +>> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +>> +>> It is more appropriate to include UUID and/or VM names in the +>> temporary filename, allowing security driver rules to be applied +>> while maintaining the required unpredictability with mkstemp. +> +> We should not have QEMU creating unpredictabile filenames in the +> first place - any filenames should be determined by libvirt +> explicitly. + +Note that the filename, per se, is not as important as other files, +since qemu won't provide it for being accessed by external programs, and, +deletes the file, while keeping the descriptor, right after its creation +(due to its nature, that is probably why it was created in /tmp). + +Having libvirt to define a filename that would not be used for recent +kernels (> 3.17) and would exist for a fraction of second doesn't seem +right to me. + +> +>> This change will allow libvirt to know exact memfd file to be created +>> for vhost log AND to create appropriate security rules to allow access +>> per instance (instead of a opened rule like <tmpdir>/memfd-*). +> +> Even with this change it is bad - we don't want driver backends +> creating arbitrary files in the shared /tmp directory. + +On the other hand, if we are creating a tmp file, like I said, I see +benefit on having unpredictability (mkstemp), but providing predictable +parts to allow security driver to apply rules per instance basis +(/tmp/memfd-UUID*, /tmp/memfd-VMname*). + +Looking forward to a decision so I can backport correct behaviour +(with or without memfd file). + +Thank you! + +Best Regards, +Rafael + + + +Hello! + +> On Sep 27, 2016, at 08:13, Marc-André Lureau <email address hidden> wrote: +> +>> Note that the filename, per se, is not as important as other files, +>> since qemu won't provide it for being accessed by external programs, and, +>> deletes the file, while keeping the descriptor, right after its creation +>> (due to its nature, that is probably why it was created in /tmp). +>> +>> Having libvirt to define a filename that would not be used for recent +>> kernels (> 3.17) and would exist for a fraction of second doesn't seem +>> right to me. +>> +> +> There are other parts of qemu that rely on creating temporary files, and this seems to lack a bit of uniformity. Would it make sense to define a place where qemu could create those? Or setting TMPDIR should help too. Could libvirt set a per-vm TMPDIR with appropriate security rules? + +You got a point. With a per-vm TMPDIR we don't have to care about filenames in future for the security driver, while still securing them per-instance base. I'll come back to you! + +Thank you! + +On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote: +> > On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> > +> > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +> >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback +> >> mechanism for systems not supporting memfd_create syscall (started +> >> being supported since 3.17). +> > +> > This is really dubious code in general and IMHO should just +> > be reverted. +> +> There are numerous people relying on older kernels in openstack +> deployments - sometimes with specific drivers (ovswitch, dpdk, +> infiniband) holding kernel upgrades - but still in need of upgrading +> userland (e.g. newer releases). Having a fallback mechanism seems +> appropriate for those cases. + +I'm not against some kind of fallback - just about the way it +silently creates files in /tmp. + +> +> Note that the filename, per se, is not as important as other files, +> since qemu won't provide it for being accessed by external programs, and, +> deletes the file, while keeping the descriptor, right after its creation +> (due to its nature, that is probably why it was created in /tmp). + +If it doesn't shared with other processes, and is deleted immediately, +why does the file need to be on disk at all ? + + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| +|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| + + +On Tue, Sep 27, 2016 at 07:13:55AM -0400, Marc-André Lureau wrote: +> Hi +> +> ----- Original Message ----- +> > +> > > On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> > > +> > > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +> > > We should not have QEMU creating unpredictabile filenames in the +> > > first place - any filenames should be determined by libvirt +> > > explicitly. +> > +> > Note that the filename, per se, is not as important as other files, +> > since qemu won't provide it for being accessed by external programs, and, +> > deletes the file, while keeping the descriptor, right after its creation +> > (due to its nature, that is probably why it was created in /tmp). +> > +> > Having libvirt to define a filename that would not be used for recent +> > kernels (> 3.17) and would exist for a fraction of second doesn't seem +> > right to me. +> > +> +> There are other parts of qemu that rely on creating temporary files, and +> this seems to lack a bit of uniformity. Would it make sense to define a +> place where qemu could create those? Or setting TMPDIR should help too. +> Could libvirt set a per-vm TMPDIR with appropriate security rules? + +The other places that use mkstemp are block for snapshot=on, which +libvirt does not support as we want control over the filename. This +needs fixing by allowing a filename to be given. The qemu sockets code +uses it for auto-creating a UNIX domain socket path, but again libvirt +doesn't support that usage. The exec.c file uses it, but that honours +an explicit directory path provided on the command line. So this memfd +code really is the first place which is causing a real + +Just setting TMPDIR per VM doesn't magically solve all these cases as +it isn't reasonable to assume that all these files should be in the +same location. Certainly block snapshot file will be somewhere different +from others, due to its size. + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| +|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| + + +Sorry, I was only able to come back to this today. + +> On Sep 27, 2016, at 09:18, Daniel Berrange <email address hidden> wrote: +> +>> There are numerous people relying on older kernels in openstack +>> deployments - sometimes with specific drivers (ovswitch, dpdk, +>> infiniband) holding kernel upgrades - but still in need of upgrading +>> userland (e.g. newer releases). Having a fallback mechanism seems +>> appropriate for those cases. +> +> I'm not against some kind of fallback - just about the way it +> silently creates files in /tmp. +> + +That is why memfd_create is used here I suppose: To allow anonymous-backed-pages to have a descriptor and to be sealed. When falling back this mechanism I don't see any other way other than creating a temporary file. Of course one way would be something like: + +http://paste.ubuntu.com/23270379/ + +But this is pretty much the same, just solving the "where to place the temporary file" (non configurable for this usage). + +>> +>> Note that the filename, per se, is not as important as other files, +>> since qemu won't provide it for being accessed by external programs, and, +>> deletes the file, while keeping the descriptor, right after its creation +>> (due to its nature, that is probably why it was created in /tmp). +> +> If it doesn't shared with other processes, and is deleted immediately, +> why does the file need to be on disk at all ? + +Well, it unlinks the file but the references are still there while the descriptor isn't closed by this process, or by the one that receives the descriptor (that is why is the "unlink" so early). + +If you check vhost_dev_log_resize(), it gets *possible* new vhost log (if a new size is given) and informs the vhost dev driver about the new log base (vhost_ops->vhost_set_log_base). + +For vhost_user, this means that the file descriptors for vhost logs are likely going to be passed to vhost backend (fds[] in vhost_user_set_log_base). This is just one example, not sure about others. + +Probably the best approach here, like what Marc-André said, is to create some sort of TMPDIR, set by libvirt perhaps ? + +> +> Regards, +> Daniel + + + +Hello Marc, + +> On Sep 27, 2016, at 08:13, Marc-André Lureau <email address hidden> wrote: +> +>>> On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: +>>> We should not have QEMU creating unpredictabile filenames in the +>>> first place - any filenames should be determined by libvirt +>>> explicitly. +>> +>> Note that the filename, per se, is not as important as other files, +>> since qemu won't provide it for being accessed by external programs, and, +>> deletes the file, while keeping the descriptor, right after its creation +>> (due to its nature, that is probably why it was created in /tmp). +>> +>> Having libvirt to define a filename that would not be used for recent +>> kernels (> 3.17) and would exist for a fraction of second doesn't seem +>> right to me. +>> +> +> There are other parts of qemu that rely on creating temporary files, and this seems to lack a bit of uniformity. Would it make sense to define a place where qemu could create those? Or setting TMPDIR should help too. Could libvirt set a per-vm TMPDIR with appropriate security rules? + +Best move I can see. Only problem is that if we do that, we would have to create a fallback mechanism for when TMPDIR is not set. It would go back to /tmp ? + +In my particular case (for 1 vhost log file): + +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3 + +I could have something similar to: + +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3,vhostpath=/var/lib/XXXX/YYYY/ + +and put mkstemp() files (one per vhost device) in there. + +Even so, what to do when "vhostpath" is not informed ? + +I'm worried that, right now there are security drivers either blocking the live migration entirely or allowing all instances to be able to read /tmp/memfd-XXXX. + +Don't you think we could push the first patch until we come up with a better approach for the tmp (and default tmp) files & directories ? The patch is not worse than what was committed already. + +Tks + +Rafael + + + + +On Mon, Oct 03, 2016 at 03:41:10PM -0000, Rafael David Tinoco wrote: +> Sorry, I was only able to come back to this today. +> +> > On Sep 27, 2016, at 09:18, Daniel Berrange <email address hidden> wrote: +> > +> >> There are numerous people relying on older kernels in openstack +> >> deployments - sometimes with specific drivers (ovswitch, dpdk, +> >> infiniband) holding kernel upgrades - but still in need of upgrading +> >> userland (e.g. newer releases). Having a fallback mechanism seems +> >> appropriate for those cases. +> > +> > I'm not against some kind of fallback - just about the way it +> > silently creates files in /tmp. +> > +> +> That is why memfd_create is used here I suppose: To allow anonymous- +> backed-pages to have a descriptor and to be sealed. When falling back +> this mechanism I don't see any other way other than creating a temporary +> file. Of course one way would be something like: +> +> http://paste.ubuntu.com/23270379/ +> +> But this is pretty much the same, just solving the "where to place the +> temporary file" (non configurable for this usage). +> +> >> +> >> Note that the filename, per se, is not as important as other files, +> >> since qemu won't provide it for being accessed by external programs, and, +> >> deletes the file, while keeping the descriptor, right after its creation +> >> (due to its nature, that is probably why it was created in /tmp). +> > +> > If it doesn't shared with other processes, and is deleted immediately, +> > why does the file need to be on disk at all ? +> +> Well, it unlinks the file but the references are still there while the +> descriptor isn't closed by this process, or by the one that receives the +> descriptor (that is why is the "unlink" so early). +> +> If you check vhost_dev_log_resize(), it gets *possible* new vhost log +> (if a new size is given) and informs the vhost dev driver about the new +> log base (vhost_ops->vhost_set_log_base). +> +> For vhost_user, this means that the file descriptors for vhost logs are +> likely going to be passed to vhost backend (fds[] in +> vhost_user_set_log_base). This is just one example, not sure about +> others. +> +> Probably the best approach here, like what Marc-André said, is to create +> some sort of TMPDIR, set by libvirt perhaps ? + +So you're saying that the file descriptor here is actually getting +passed to a different process for it to use ? + +If so that means we definitely do not want this in TMPDIR. If we +create a generic file in TMPDIR, then its going to have a generic +security label. That means that the other process we're giving the +FD to is going to have to be granted permission to access this FD +and we certainly don't want to grant permission for it to access +any of QEMU's other FDs. So for the SELinux integration, we'll +need this FD to be in a specific directory, so that we can setup +policy such that the file created gets given a specific SELinux +label. We can then grant the other process access to only that +particular file, and not anything else of QEMU's. + +This makes me wonder about the memfd_create() code path too - we'll +again not want that external process to be granted access to arbitrary +FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +a specific label. So I think it is possible that when using libvirt +we'll want the ability to tell QEMU to *always* use an explicit file +in a path libvirt specifies, and never use memfd even if available. + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + +Hello Daniel, + +> On Oct 03, 2016, at 14:55, Daniel P. Berrange <email address hidden> wrote: +> +>> Well, it unlinks the file but the references are still there while the +>> descriptor isn't closed by this process, or by the one that receives the +>> descriptor (that is why is the "unlink" so early). +>> +>> If you check vhost_dev_log_resize(), it gets *possible* new vhost log +>> (if a new size is given) and informs the vhost dev driver about the new +>> log base (vhost_ops->vhost_set_log_base). +>> +>> For vhost_user, this means that the file descriptors for vhost logs are +>> likely going to be passed to vhost backend (fds[] in +>> vhost_user_set_log_base). This is just one example, not sure about +>> others. +>> +>> Probably the best approach here, like what Marc-André said, is to create +>> some sort of TMPDIR, set by libvirt perhaps ? +> +> So you're saying that the file descriptor here is actually getting +> passed to a different process for it to use ? +> +> If so that means we definitely do not want this in TMPDIR. If we +> create a generic file in TMPDIR, then its going to have a generic +> security label. That means that the other process we're giving the +> FD to is going to have to be granted permission to access this FD +> and we certainly don't want to grant permission for it to access +> any of QEMU's other FDs. So for the SELinux integration, we'll +> need this FD to be in a specific directory, so that we can setup +> policy such that the file created gets given a specific SELinux +> label. We can then grant the other process access to only that +> particular file, and not anything else of QEMU's. +> +> This makes me wonder about the memfd_create() code path too - we'll +> again not want that external process to be granted access to arbitrary +> FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +> a specific label. So I think it is possible that when using libvirt +> we'll want the ability to tell QEMU to *always* use an explicit file +> in a path libvirt specifies, and never use memfd even if available. + +Check this execution path: + +(vhost_vsock_device_realize) + vhost_dev_init + vhost_commit + |- vhost_get_log_size + |... + |- vhost_dev_log_resize + +(vhost_dev_log_resize): + vhost_log_get -> here if the size is bigger, a new log is created + dev->vhost_ops->vhost_set_log_base() -> kernel or user vhost driver + vhost_log_put() + +---- + +So, + +* In case of the kernel mode, this is just a: + +vhost in kernel mode = vhost_kernel_set_log_base +return vhost_kernel_call(dev, VHOST_SET_LOG_BASE, &base); + +which makes an ioctl to dev->opaque file descriptor to set a new vhost log base. + +* But in the case of user mode: + +vhost in user mode = vhost_user_set_log_base + +which gets the log file descriptor (log->fd) and gives to vhost_user_write. vhost_user_write will do a qemu_chr_fe_set_msgfds passing the log file descriptors for the backend vhost driver (CharDriverState). + +If I'm reading this right.. if the backend driver is: + +static int tcp_set_msgfds(CharDriverState *chr, int *fds, int num) + +it would check for: + +!qio_channel_has_feature(s->ioc, QIO_CHANNEL_FEATURE_FD_PASS)) { + +and configure s->write_msgfds. This would be sent in: + +static int tcp_chr_write(CharDriverState *chr, const uint8_t *buf, int len) + +with "io_channel_send_full" + "qio_channel_writev_full + io_writev from QIOChannelClass. + +---- + +https://www.berrange.com/posts/2016/08/16/ + +This, from your blog, probably confirms this behaviour: + +"The migration code supports a number of different protocols besides just “tcp:“. In particular it allows an “fd:” protocol to tell QEMU to use a passed-in file descriptor, and an “exec:” protocol to tell QEMU to launch an external command to tunnel the connection. It is desirable to be able to use TLS with these protocols too, but when using TLS the client QEMU needs to know the hostname of the target QEMU in order to correctly validate the x509 certificate it receives. Thus, a second “tls-hostname” parameter was added to allow QEMU to be informed of the hostname to use for x509 certificate validation when using a non-tcp migration protocol. This can be set on the source QEMU prior to starting the migration using the “migrate_set_str_parameter” monitor command" + +=) + +Yes, definitely. Check this: + +/** + * @qemu_chr_fe_set_msgfds: + * + * For backends capable of fd passing, set an array of fds to be passed with + * the next send operation. + * A subsequent call to this function before calling a write function will + * result in overwriting the fd array with the new value without being send. + * Upon writing the message the fd array is freed. + * + * Returns: -1 if fd passing isn't supported. + */ +int qemu_chr_fe_set_msgfds(CharDriverState *s, int *fds, int num); + +---- + +So, at least for vhost_dev_log_resize, this "interface" is being implemented: + +vhost_user_set_log_base -> VhostUserMsg = VHOST_USER_SET_LOG_BASE + +vhost_user_write(with the VHOST_USER_GET_LOG_BASE message): + +- configures the file descriptors(... , fds, fd_num) + qemu_chr_fe_set_msgfds + +- writes them down the char driver + qemu_chr_fe_write_all + +> On Oct 03, 2016, at 15:46, Rafael David Tinoco <email address hidden> wrote: +> +>> So you're saying that the file descriptor here is actually getting +>> passed to a different process for it to use ? + + + +On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> Yes, definitely. Check this: + +[snip] + +So in that case, I think we must add ability to specify an explicit path +that apps can use *regardles* of whether memfd support exists or not. + +> > On Oct 03, 2016, at 15:46, Rafael David Tinoco <email address hidden> wrote: +> > +> >> So you're saying that the file descriptor here is actually getting +> >> passed to a different process for it to use ? +> + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + +Let me work on it. I'll get back soon. + +Tks Daniel. + +> On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote: +> +> On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +>> Yes, definitely. Check this: +> +> [snip] +> +> So in that case, I think we must add ability to specify an explicit path +> that apps can use *regardles* of whether memfd support exists or not. +> +>>> On Oct 03, 2016, at 15:46, Rafael David Tinoco <email address hidden> wrote: +>>> +>>>> So you're saying that the file descriptor here is actually getting +>>>> passed to a different process for it to use ? + + + +Hi Rafael, Daniel, + +On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +<email address hidden>> wrote: + +> Let me work on it. I'll get back soon. +> +> +thanks for working on it, before that I have a few questions: + +Tks Daniel. +> +> > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> wrote: +> > +> > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> >> Yes, definitely. Check this: +> > +> > [snip] +> > +> > So in that case, I think we must add ability to specify an explicit path +> > that apps can use *regardles* of whether memfd support exists or not. +> + +How will this path be used? Is it going to be global to qemu for various +use (kinda like $TMP), or per-device, or for memfd fallback only? Should +the path pre-exist? (I suppose, if not, qemu should clean it up when +leaving) + +> +> >>> On Oct 03, 2016, at 15:46, Rafael David Tinoco < +> <email address hidden>> wrote: +> >>> +> >>>> So you're saying that the file descriptor here is actually getting +> >>>> passed to a different process for it to use ? +> +> +> -- +Marc-André Lureau + + +On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> Hi Rafael, Daniel, +> +> On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> <email address hidden>> wrote: +> +> > Let me work on it. I'll get back soon. +> > +> > +> thanks for working on it, before that I have a few questions: +> +> Tks Daniel. +> > +> > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> > wrote: +> > > +> > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> > >> Yes, definitely. Check this: +> > > +> > > [snip] +> > > +> > > So in that case, I think we must add ability to specify an explicit path +> > > that apps can use *regardles* of whether memfd support exists or not. +> > +> +> How will this path be used? Is it going to be global to qemu for various +> use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> the path pre-exist? (I suppose, if not, qemu should clean it up when +> leaving) + +I'd expect it to be an option set against the vhost user backend, since +that's the thing using this. + +If other things have similar usage needs wrt memfd in future, they would +also need similar path config option. + + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + +Hi + +On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden> +wrote: + +> On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> > Hi Rafael, Daniel, +> > +> > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> > <email address hidden>> wrote: +> > +> > > Let me work on it. I'll get back soon. +> > > +> > > +> > thanks for working on it, before that I have a few questions: +> > +> > Tks Daniel. +> > > +> > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> > > wrote: +> > > > +> > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> > > >> Yes, definitely. Check this: +> > > > +> > > > [snip] +> > > > +> > > > So in that case, I think we must add ability to specify an explicit +> path +> > > > that apps can use *regardles* of whether memfd support exists or not. +> > > +> > +> > How will this path be used? Is it going to be global to qemu for various +> > use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > leaving) +> +> I'd expect it to be an option set against the vhost user backend, since +> that's the thing using this. +> +> If other things have similar usage needs wrt memfd in future, they would +> also need similar path config option. +> + +The log may be shared if there are several vhost-user (stored in +vhost_log_shm global), so I think it makes more sense to have a global +config path for it, or you may end up duplicating that information per +vhost backend and having files in either of the specified paths. + + +> +> +> Regards, +> Daniel +> -- +> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ +> :| +> |: http://libvirt.org -o- http://virt-manager.org +> :| +> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ +> :| +> +-- +Marc-André Lureau + + +On Tue, Oct 04, 2016 at 01:10:17PM +0000, Marc-André Lureau wrote: +> Hi +> +> On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden> +> wrote: +> +> > On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> > > Hi Rafael, Daniel, +> > > +> > > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> > > <email address hidden>> wrote: +> > > +> > > > Let me work on it. I'll get back soon. +> > > > +> > > > +> > > thanks for working on it, before that I have a few questions: +> > > +> > > Tks Daniel. +> > > > +> > > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange <email address hidden> +> > > > wrote: +> > > > > +> > > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: +> > > > >> Yes, definitely. Check this: +> > > > > +> > > > > [snip] +> > > > > +> > > > > So in that case, I think we must add ability to specify an explicit +> > path +> > > > > that apps can use *regardles* of whether memfd support exists or not. +> > > > +> > > +> > > How will this path be used? Is it going to be global to qemu for various +> > > use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> > > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > > leaving) +> > +> > I'd expect it to be an option set against the vhost user backend, since +> > that's the thing using this. +> > +> > If other things have similar usage needs wrt memfd in future, they would +> > also need similar path config option. +> > +> +> The log may be shared if there are several vhost-user (stored in +> vhost_log_shm global), so I think it makes more sense to have a global +> config path for it, or you may end up duplicating that information per +> vhost backend and having files in either of the specified paths. + +Hmm, is there a reason why it is shared? That seems to make an assumption +that all vhost-user backends would be managed by the same external process. +While that may be the common case today, it doesn't feel like a reasonable +assumption to make long term. IOW it feels wiser to have it set per-NIC +unless I'm missing something important that means it must be shared ? + +Regards, +Daniel +-- +|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| +|: http://libvirt.org -o- http://virt-manager.org :| +|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| + + + +> On Oct 04, 2016, at 10:10, Marc-André Lureau <email address hidden> wrote: +> +> > How will this path be used? Is it going to be global to qemu for various +> > use (kinda like $TMP), or per-device, or for memfd fallback only? Should +> > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > leaving) +> +> I'd expect it to be an option set against the vhost user backend, since +> that's the thing using this. +> +> If other things have similar usage needs wrt memfd in future, they would +> also need similar path config option. + +I was going for that approach. I could have something similar to: + +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:5c:10:f2,bus=pci.0,addr=0x3,vhostpath=/var/lib/XXXX/YYYY/ + +> The log may be shared if there are several vhost-user (stored in vhost_log_shm global), so I think it makes more sense to have a global config path for it, or you may end up duplicating that information per vhost backend and having files in either of the specified paths. + +But, yes, indeed the vhost_log_shm makes that approach tricky. If sharing the same log file with multiple vhost backend. Besides, tools like openstack would put all the vhost log files in the same place at the end. + +Having a global config path, forced to be specified, orelse the vhost log isn't created, like when it fails nowadays. This seems to be the right approach. + +True. + +What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. + +This way every device would get its own log file and vhost-user backends would be able to get its file descriptors. (and, of course, allow the security drivers to do their jobs). + +>> On Oct 04, 2016, at 10:25, Daniel P. Berrange <email address hidden> wrote: +>> +>> Hmm, is there a reason why it is shared? That seems to make an assumption +>> that all vhost-user backends would be managed by the same external process. +>> While that may be the common case today, it doesn't feel like a reasonable +>> assumption to make long term. IOW it feels wiser to have it set per-NIC +>> unless I'm missing something important that means it must be shared ? +> + + + +Hi + +On Tue, Oct 4, 2016 at 5:25 PM Daniel P. Berrange <email address hidden> +wrote: + +> On Tue, Oct 04, 2016 at 01:10:17PM +0000, Marc-André Lureau wrote: +> > Hi +> > +> > On Tue, Oct 4, 2016 at 4:42 PM Daniel P. Berrange <email address hidden> +> > wrote: +> > +> > > On Tue, Oct 04, 2016 at 12:39:17PM +0000, Marc-André Lureau wrote: +> > > > Hi Rafael, Daniel, +> > > > +> > > > On Tue, Oct 4, 2016 at 4:22 PM Rafael David Tinoco < +> > > > <email address hidden>> wrote: +> > > > +> > > > > Let me work on it. I'll get back soon. +> > > > > +> > > > > +> > > > thanks for working on it, before that I have a few questions: +> > > > +> > > > Tks Daniel. +> > > > > +> > > > > > On Oct 04, 2016, at 05:36, Daniel P. Berrange < +> <email address hidden>> +> > > > > wrote: +> > > > > > +> > > > > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco +> wrote: +> > > > > >> Yes, definitely. Check this: +> > > > > > +> > > > > > [snip] +> > > > > > +> > > > > > So in that case, I think we must add ability to specify an +> explicit +> > > path +> > > > > > that apps can use *regardles* of whether memfd support exists or +> not. +> > > > > +> > > > +> > > > How will this path be used? Is it going to be global to qemu for +> various +> > > > use (kinda like $TMP), or per-device, or for memfd fallback only? +> Should +> > > > the path pre-exist? (I suppose, if not, qemu should clean it up when +> > > > leaving) +> > > +> > > I'd expect it to be an option set against the vhost user backend, since +> > > that's the thing using this. +> > > +> > > If other things have similar usage needs wrt memfd in future, they +> would +> > > also need similar path config option. +> > > +> > +> > The log may be shared if there are several vhost-user (stored in +> > vhost_log_shm global), so I think it makes more sense to have a global +> > config path for it, or you may end up duplicating that information per +> > vhost backend and having files in either of the specified paths. +> +> Hmm, is there a reason why it is shared? That seems to make an assumption +> that all vhost-user backends would be managed by the same external process. +> While that may be the common case today, it doesn't feel like a reasonable +> assumption to make long term. IOW it feels wiser to have it set per-NIC +> unless I'm missing something important that means it must be shared ? +> +> +It's a shared log, just like they share the same ram. Duplicating the log +would mostly make migration more difficult to handle and increase a bit +memory usage. + + +> Regards, +> Daniel +> -- +> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ +> :| +> |: http://libvirt.org -o- http://virt-manager.org +> :| +> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ +> :| +> +-- +Marc-André Lureau + + +On Tue, Oct 4, 2016 at 5:34 PM Rafael David Tinoco < +<email address hidden>> wrote: + +> True. +> +> What about having a single config parameter as a place to put all vhost +> logs for all drives for a single instance ? Remove the memfd implementation +> with all the memfd shared_memory option ? Replace it with a +> open+unlink+ftruncate+mmap approach only. +> +> +I fail to see your point, memfd is superior to open+unlink and has other +advantages with sealing etc. + +Regarding shared log, see my previous reply to Daniel. + +This way every device would get its own log file and vhost-user backends +> would be able to get its file descriptors. (and, of course, allow the +> security drivers to do their jobs). +> +> >> On Oct 04, 2016, at 10:25, Daniel P. Berrange <email address hidden> +> wrote: +> >> +> >> Hmm, is there a reason why it is shared? That seems to make an +> assumption +> >> that all vhost-user backends would be managed by the same external +> process. +> >> While that may be the common case today, it doesn't feel like a +> reasonable +> >> assumption to make long term. IOW it feels wiser to have it set per-NIC +> >> unless I'm missing something important that means it must be shared ? +> > +> +> -- +Marc-André Lureau + + + +> On Oct 04, 2016, at 10:50, Marc-André Lureau <email address hidden> wrote: +> +> What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. +> +> +> I fail to see your point, memfd is superior to open+unlink and has other advantages with sealing etc. + +I was just summarising needs based on previous statement from Daniel: + +> This makes me wonder about the memfd_create() code path too - we'll +> again not want that external process to be granted access to arbitrary +> FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +> a specific label. So I think it is possible that when using libvirt +> we'll want the ability to tell QEMU to *always* use an explicit file +> in a path libvirt specifies, and never use memfd even if available. +> +> Regards, +> Daniel + + +Hello Again, finally I could get back to this, and.. + +I was finishing a patch creating the open+truncate+mmap+unlink mechanism on files specified by "vhostlog" parameter of tap devices. Patch is done, problem is that... looks like the "memfd" is only used for shared logs AND vhost-net (used for tap devices) doesn't use it. + +In the following... + +(scenario 1) + +Linux kvm01 4.8.0-22-generic #24-Ubuntu SMP Sat Oct 8 09:15:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux + +with: +-netdev tap,id=net0,vhost=on +-device virtio-net-pci,netdev=net0,id=net0,mac=52:54:00:20:c5:42,bus=pci.0,addr=0x3 + +## kvm01 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create worked, truncating... +qemu_memfd_alloc: mmaping +qemu_memfd_free: enter +qemu_memfd_check: ok +vhost_dev_start: enter +vhost_log_get: enter +vhost_log_alloc: enter +vhost_log_alloc: local +vhost_log_get: not shared +vhost_log_put: enter +vhost_log_put: enter +vhost_log_put: local free + +(qemu) migrate -d tcp:kvm02:4444 +(qemu) info migrate +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compres +Migration status: completed +total time: 14586 milliseconds +downtime: 10 milliseconds +setup: 20 milliseconds +transferred ram: 377224 kbytes +throughput: 212.02 mbps +remaining ram: 0 kbytes +total ram: 4001544 kbytes +duplicate: 908879 pages +skipped: 0 pages +normal: 92129 pages +normal bytes: 368516 kbytes +dirty sync count: 4 + +## kvm02 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create worked, truncating... +qemu_memfd_alloc: mmaping +qemu_memfd_free: enter +qemu_memfd_check: ok +vhost_dev_start: enter + +(scenario 2) + +Linux kvm01 3.13.0-99-generic #146-Ubuntu SMP Wed Oct 12 20:56:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux + +with: +-netdev tap,id=net0,vhost=on +-device virtio-net-pci,netdev=net0,id=net0,mac=52:54:00:20:c5:42,bus=pci.0,addr=0x3 + +## kvm01 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create failed #2 +qemu_memfd_alloc: fallback +qemu_memfd_alloc: fname = /tmp/memfd-XXXXXX +qemu_memfd_alloc: fallback truncating +qemu_memfd_alloc: mmaping +qemu_memfd_free +qemu_memfd_check: ok +vhost_dev_start: enter +vhost_log_get: enter +vhost_log_alloc: enter +vhost_log_alloc: local +vhost_log_get: not shared +vhost_log_put: enter +vhost_log_put: enter +vhost_log_put: local free + +(qemu) migrate -d tcp:kvm02:4444 +(qemu) info migrate +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compres +Migration status: completed +total time: 15400 milliseconds +downtime: 9 milliseconds +setup: 5 milliseconds +transferred ram: 375812 kbytes +throughput: 199.99 mbps +remaining ram: 0 kbytes +total ram: 4001544 kbytes +duplicate: 909186 pages +skipped: 0 pages +normal: 91776 pages +normal bytes: 367104 kbytes +dirty sync count: 3 + +## kvm02 + +$ ./instance.sh +qemu_memfd_check +qemu_memfd_alloc: enter +qemu_memfd_alloc: memfd_create with no sealing +qemu_memfd_alloc: memfd_create failed #2 +qemu_memfd_alloc: fallback +qemu_memfd_alloc: fname = /tmp/memfd-XXXXXX +qemu_memfd_alloc: fallback truncating +qemu_memfd_alloc: mmaping +qemu_memfd_free +qemu_memfd_check: ok +vhost_dev_start: enter + +For kvm01, we have 2 parts: + +(1) From "-netdev tap,id=net0,vhost=on": + - net_init_clients() + - net_init_client() + - net_client_init() + - net_client_init1() + - net_client_init_fun() .. net_init_tap() in my case + - net_init_tap_one() + - vhost_net_init() + - vhost_dev_init() + - migration checks (host feature, memfd functional test) + +(2) From "-device virtio-net-pci,netdev=net0...": + - virtio_pci_device_plugged() + - virtio_pci_modern_regions_init() + - virtio_pci_common_write() + - virtio_set_status() + - virtio_net_set_status() + - virtio_net_vhost_status() + - vhost_net_start() + - vhost_net_start_one() + - vhost_dev_start() + - does the log allocation logic + +It looks like "vhost_requires_shm_log" isn't defined by my underlaying VHOST driver (vhost-net in my case). It seems that vhost-user defines it (from VhostOps user_ops). + +Judging by the outputs above, looks like vhost_dev_log_is_shared is returning false, making (2) - vhost_dev_start - to use a different log allocation (malloc) than the one that was tested for allowing migrations at (1) - vhost_dev_init. + +Question: Why to check for "memfd" when its not sure - yet - if a shared descriptor and memory pointer is going to be needed for the migration to happen ? Do you want me to change that ? If memfd fails, but, the guest in question is using regular "malloc" for vhost log, we are marking it unable to live migrate by mistake. I could check for vhost_requires_shm_log pointer during vhost_dev_init (coming from tap). + +Also, if possible, I would like comments about a draft: + +https://pastebin.canonical.com/168579/ +(please disregard printfs and minor problems) + +OBS: I'm basically removing fallback mechanism from memfd, creating a generic qemu_mmap_XXX implementation, adding a vhostlog parameter in tap cmdline AND changing the decision on what to use: if vhostlog is present in cmdline, qemu_mmap_XXX on vhostlog is used. If it is a directory, a random file is created inside it. If it is a file, the file is used. If no vhostlog is given (default while libvirt isn't changed), it tries first to use memfd (all newer kernels), and, if not possible, it tries to fallback using the qemu_mmap mechanism on "tmp" directory creating random files. + +PS: Remember that this is because selinux/apparmor labelling on tmp files (and because file descriptors can be passed away, like we discussed before). + +If that is okay I'll provide a patch asap. Let me know if you prefer something else. + +Thank you, +Rafael + +> On Oct 04, 2016, at 12:29, Rafael David Tinoco <email address hidden> wrote: +> +> +>> On Oct 04, 2016, at 10:50, Marc-André Lureau <email address hidden> wrote: +>> +>> What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. +>> +>> +>> I fail to see your point, memfd is superior to open+unlink and has other advantages with sealing etc. +> +> I was just summarising needs based on previous statement from Daniel: +> +>> This makes me wonder about the memfd_create() code path too - we'll +>> again not want that external process to be granted access to arbitrary +>> FDs of QEMU's and I'm not sure of a way to get the memfd FD to have +>> a specific label. So I think it is possible that when using libvirt +>> we'll want the ability to tell QEMU to *always* use an explicit file +>> in a path libvirt specifies, and never use memfd even if available. +>> +>> Regards, +>> Daniel + + + +The correct (and draft) one: +http://pastebin.ubuntu.com/23357210/ + +Im passing vhostlog parameter as "hdev->log_filename" so it can be accessed from net_init_tap()-> functions AND from vhost_dev_start()-> functions. This way I don't have to change function prototypes anymore. + +> On Oct 21, 2016, at 01:03, Rafael David Tinoco <email address hidden> wrote: +> +> Also, if possible, I would like comments about a draft: +> +> https://pastebin.canonical.com/168579/ +> (please disregard printfs and minor problems) + + + +Hi + +On Fri, Oct 21, 2016 at 6:03 AM Rafael David Tinoco < +<email address hidden>> wrote: + +> Judging by the outputs above, looks like vhost_dev_log_is_shared is +> returning false, making (2) - vhost_dev_start - to use a different log +> allocation (malloc) than the one that was tested for allowing migrations at +> (1) - vhost_dev_init. +> +> +correct + + +> Question: Why to check for "memfd" when its not sure - yet - if a shared +> descriptor and memory pointer is going to be needed for the migration to +> happen ? Do you want me to + + +It's done early enough to disable migration. + + +> change that ? If memfd fails, but, the guest in question is using regular +> "malloc" for vhost log, we are marking it unable to live migrate by +> mistake. I could check for vhost_requires_shm_log pointer during +> vhost_dev_init (coming from tap). +> +> +Right, it should be done only if vhost_dev_log_is_shared is true. Patch +welcome + + +> Also, if possible, I would like comments about a draft: +> +> https://pastebin.canonical.com/168579/ +> (please disregard printfs and minor problems) +> +> OBS: I'm basically removing fallback mechanism from memfd, creating a +> generic qemu_mmap_XXX implementation, adding a vhostlog parameter in tap +> cmdline AND changing the decision on what to use: if vhostlog is present in +> cmdline, qemu_mmap_XXX on vhostlog is used. If it is a directory, a random +> file is created inside it. If it is a file, the file is used. If no +> vhostlog is given (default while libvirt isn't changed), it tries first to +> use memfd (all newer kernels), and, if not possible, it tries to fallback +> using the qemu_mmap mechanism on "tmp" directory creating random files. +> + +Sounds reasonable, but I am not sure so many fallbacks are necessary. I +would just have an optional filename. + +> +> PS: Remember that this is because selinux/apparmor labelling on tmp files +> (and because file descriptors can be passed away, like we discussed before). +> +> If that is okay I'll provide a patch asap. Let me know if you prefer +> something else. +> + +Ok, I hope other comments on the idea, and I'll review your patch once on +the ML. + +Thanks +-- +Marc-André Lureau + + +Commit 31190ed7 added a migration blocker in vhost_dev_init() to +check if memfd would succeed. It is better if this blocker first +checks if vhost backend requires shared log. This will avoid a +situation where a blocker is added inappropriately (e.g. shared +log allocation fails when vhost backend doesn't support it). + +Commit: 35f9b6e added a fallback mechanism for systems not supporting +memfd_create syscall (started being supported since 3.17). + +Backporting memfd_create might not be accepted for distros relying +on older kernels. Nowadays there is no way for security driver +to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. + +Also, because vhost log file descriptors can be passed to other +processes, after discussion, we thought it is best to back mmap by +using files that can be placed into a specific directory: this commit +creates "vhostlog" argv parameter for such purpose. This will allow +security drivers to operate on those files appropriately. + +Argv examples: + + -netdev tap,id=net0,vhost=on + -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log + -netdev tap,id=net0,vhost=on,vhostlog=/tmp + +For vhost backends supporting shared logs, if vhostlog is non-existent, +or a directory, random files are going to be created in the specified +directory (or, for non-existent, in tmpdir). If vhostlog is specified, +the filepath is always used when allocating vhost log files. + +Signed-off-by: Rafael David Tinoco <email address hidden> +--- + hw/net/vhost_net.c | 4 +- + hw/scsi/vhost-scsi.c | 2 +- + hw/virtio/vhost-vsock.c | 2 +- + hw/virtio/vhost.c | 41 +++++++------ + include/hw/virtio/vhost.h | 4 +- + include/net/vhost_net.h | 1 + + include/qemu/mmap-file.h | 10 +++ + net/tap.c | 6 ++ + qapi-schema.json | 3 + + qemu-options.hx | 3 +- + util/Makefile.objs | 1 + + util/mmap-file.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++ + 12 files changed, 207 insertions(+), 23 deletions(-) + create mode 100644 include/qemu/mmap-file.h + create mode 100644 util/mmap-file.c + +diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c +index f2d49ad..d650c92 100644 +--- a/hw/net/vhost_net.c ++++ b/hw/net/vhost_net.c +@@ -171,8 +171,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) + net->dev.vq_index = net->nc->queue_index * net->dev.nvqs; + } + +- r = vhost_dev_init(&net->dev, options->opaque, +- options->backend_type, options->busyloop_timeout); ++ r = vhost_dev_init(&net->dev, options->opaque, options->backend_type, ++ options->busyloop_timeout, options->vhostlog); + if (r < 0) { + goto fail; + } +diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c +index 5b26946..5dc3d30 100644 +--- a/hw/scsi/vhost-scsi.c ++++ b/hw/scsi/vhost-scsi.c +@@ -248,7 +248,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) + s->dev.backend_features = 0; + + ret = vhost_dev_init(&s->dev, (void *)(uintptr_t)vhostfd, +- VHOST_BACKEND_TYPE_KERNEL, 0); ++ VHOST_BACKEND_TYPE_KERNEL, 0, NULL); + if (ret < 0) { + error_setg(errp, "vhost-scsi: vhost initialization failed: %s", + strerror(-ret)); +diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c +index b481562..6cf6081 100644 +--- a/hw/virtio/vhost-vsock.c ++++ b/hw/virtio/vhost-vsock.c +@@ -342,7 +342,7 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp) + vsock->vhost_dev.nvqs = ARRAY_SIZE(vsock->vhost_vqs); + vsock->vhost_dev.vqs = vsock->vhost_vqs; + ret = vhost_dev_init(&vsock->vhost_dev, (void *)(uintptr_t)vhostfd, +- VHOST_BACKEND_TYPE_KERNEL, 0); ++ VHOST_BACKEND_TYPE_KERNEL, 0, NULL); + if (ret < 0) { + error_setg_errno(errp, -ret, "vhost-vsock: vhost_dev_init failed"); + goto err_virtio; +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index bd051ab..d874ebb 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -20,7 +20,7 @@ + #include "qemu/atomic.h" + #include "qemu/range.h" + #include "qemu/error-report.h" +-#include "qemu/memfd.h" ++#include "qemu/mmap-file.h" + #include <linux/vhost.h> + #include "exec/address-spaces.h" + #include "hw/virtio/virtio-bus.h" +@@ -326,7 +326,7 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev) + return log_size; + } + +-static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) ++static struct vhost_log *vhost_log_alloc(char *path, uint64_t size, bool share) + { + struct vhost_log *log; + uint64_t logsize = size * sizeof(*(log->log)); +@@ -334,9 +334,7 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) + + log = g_new0(struct vhost_log, 1); + if (share) { +- log->log = qemu_memfd_alloc("vhost-log", logsize, +- F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, +- &fd); ++ log->log = qemu_mmap_alloc(path, logsize, &fd); + memset(log->log, 0, logsize); + } else { + log->log = g_malloc0(logsize); +@@ -349,12 +347,12 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) + return log; + } + +-static struct vhost_log *vhost_log_get(uint64_t size, bool share) ++static struct vhost_log *vhost_log_get(char *path, uint64_t size, bool share) + { + struct vhost_log *log = share ? vhost_log_shm : vhost_log; + + if (!log || log->size != size) { +- log = vhost_log_alloc(size, share); ++ log = vhost_log_alloc(path, size, share); + if (share) { + vhost_log_shm = log; + } else { +@@ -388,8 +386,7 @@ static void vhost_log_put(struct vhost_dev *dev, bool sync) + g_free(log->log); + vhost_log = NULL; + } else if (vhost_log_shm == log) { +- qemu_memfd_free(log->log, log->size * sizeof(*(log->log)), +- log->fd); ++ qemu_mmap_free(log->log, log->size * sizeof(*(log->log)), log->fd); + vhost_log_shm = NULL; + } + +@@ -405,9 +402,12 @@ static bool vhost_dev_log_is_shared(struct vhost_dev *dev) + + static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t size) + { +- struct vhost_log *log = vhost_log_get(size, vhost_dev_log_is_shared(dev)); +- uint64_t log_base = (uintptr_t)log->log; + int r; ++ struct vhost_log *log; ++ uint64_t log_base; ++ ++ log = vhost_log_get(dev->log_filename, size, vhost_dev_log_is_shared(dev)); ++ log_base = (uintptr_t)log->log; + + /* inform backend of log switching, this must be done before + releasing the current log, to ensure no logging is lost */ +@@ -1049,7 +1049,8 @@ static void vhost_virtqueue_cleanup(struct vhost_virtqueue *vq) + } + + int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +- VhostBackendType backend_type, uint32_t busyloop_timeout) ++ VhostBackendType backend_type, ++ uint32_t busyloop_timeout, char *vhostlog) + { + uint64_t features; + int i, r, n_initialized_vqs = 0; +@@ -1118,11 +1119,18 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + .priority = 10 + }; + ++ hdev->log = NULL; ++ hdev->log_size = 0; ++ hdev->log_enabled = false; ++ hdev->log_filename = vhostlog ? g_strdup(vhostlog) : NULL; ++ g_free(vhostlog); ++ + if (hdev->migration_blocker == NULL) { + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && ++ !qemu_mmap_check(hdev->log_filename)) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } +@@ -1135,9 +1143,6 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions)); + hdev->n_mem_sections = 0; + hdev->mem_sections = NULL; +- hdev->log = NULL; +- hdev->log_size = 0; +- hdev->log_enabled = false; + hdev->started = false; + hdev->memory_changed = false; + memory_listener_register(&hdev->memory_listener, &address_space_memory); +@@ -1175,6 +1180,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev) + if (hdev->vhost_ops) { + hdev->vhost_ops->vhost_backend_cleanup(hdev); + } ++ g_free(hdev->log_filename); + assert(!hdev->log); + + memset(hdev, 0, sizeof(struct vhost_dev)); +@@ -1335,7 +1341,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) + uint64_t log_base; + + hdev->log_size = vhost_get_log_size(hdev); +- hdev->log = vhost_log_get(hdev->log_size, ++ hdev->log = vhost_log_get(hdev->log_filename, ++ hdev->log_size, + vhost_dev_log_is_shared(hdev)); + log_base = (uintptr_t)hdev->log->log; + r = hdev->vhost_ops->vhost_set_log_base(hdev, +diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h +index e433089..1ea4f3a 100644 +--- a/include/hw/virtio/vhost.h ++++ b/include/hw/virtio/vhost.h +@@ -52,6 +52,7 @@ struct vhost_dev { + uint64_t max_queues; + bool started; + bool log_enabled; ++ char *log_filename; + uint64_t log_size; + Error *migration_blocker; + bool memory_changed; +@@ -65,7 +66,8 @@ struct vhost_dev { + + int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + VhostBackendType backend_type, +- uint32_t busyloop_timeout); ++ uint32_t busyloop_timeout, ++ char *vhostlog); + void vhost_dev_cleanup(struct vhost_dev *hdev); + int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev); + void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev); +diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h +index 5a08eff..94161b2 100644 +--- a/include/net/vhost_net.h ++++ b/include/net/vhost_net.h +@@ -12,6 +12,7 @@ typedef struct VhostNetOptions { + NetClientState *net_backend; + uint32_t busyloop_timeout; + void *opaque; ++ char *vhostlog; + } VhostNetOptions; + + uint64_t vhost_net_get_max_queues(VHostNetState *net); +diff --git a/include/qemu/mmap-file.h b/include/qemu/mmap-file.h +new file mode 100644 +index 0000000..427612a +--- /dev/null ++++ b/include/qemu/mmap-file.h +@@ -0,0 +1,10 @@ ++#ifndef QEMU_MMAP_FILE_H ++#define QEMU_MMAP_FILE_H ++ ++#include "qemu-common.h" ++ ++void *qemu_mmap_alloc(const char *path, size_t size, int *fd); ++void qemu_mmap_free(void *ptr, size_t size, int fd); ++bool qemu_mmap_check(const char *path); ++ ++#endif +diff --git a/net/tap.c b/net/tap.c +index b6896a7..7b242cd 100644 +--- a/net/tap.c ++++ b/net/tap.c +@@ -699,6 +699,12 @@ static void net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, + } + options.opaque = (void *)(uintptr_t)vhostfd; + ++ if (tap->has_vhostlog) { ++ options.vhostlog = g_strdup(tap->vhostlog); ++ } else { ++ options.vhostlog = NULL; ++ } ++ + s->vhost_net = vhost_net_init(&options); + if (!s->vhost_net) { + error_setg(errp, +diff --git a/qapi-schema.json b/qapi-schema.json +index 5a8ec38..72608bd 100644 +--- a/qapi-schema.json ++++ b/qapi-schema.json +@@ -2640,6 +2640,8 @@ + # + # @vhostforce: #optional vhost on for non-MSIX virtio guests + # ++# @vhostlog: #optional file or directory for vhost backend log ++# + # @queues: #optional number of queues to be created for multiqueue capable tap + # + # @poll-us: #optional maximum number of microseconds that could +@@ -2662,6 +2664,7 @@ + '*vhostfd': 'str', + '*vhostfds': 'str', + '*vhostforce': 'bool', ++ '*vhostlog': 'str', + '*queues': 'uint32', + '*poll-us': 'uint32'} } + +diff --git a/qemu-options.hx b/qemu-options.hx +index b1fbdb0..5c09c09 100644 +--- a/qemu-options.hx ++++ b/qemu-options.hx +@@ -1599,7 +1599,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, + #else + "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" + " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" +- " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" ++ " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,vhostlog=file|dir][,queues=n]\n" + " [,poll-us=n]\n" + " configure a host TAP network backend with ID 'str'\n" + " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" +@@ -1618,6 +1618,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, + " use vhost=on to enable experimental in kernel accelerator\n" + " (only has effect for virtio guests which use MSIX)\n" + " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" ++ " use 'vhostlog=file|dir' file or directory for vhost backend log\n" + " use 'vhostfd=h' to connect to an already opened vhost net device\n" + " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" + " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" +diff --git a/util/Makefile.objs b/util/Makefile.objs +index 36c7dcc..69bb27a 100644 +--- a/util/Makefile.objs ++++ b/util/Makefile.objs +@@ -3,6 +3,7 @@ util-obj-y += bufferiszero.o + util-obj-$(CONFIG_POSIX) += compatfd.o + util-obj-$(CONFIG_POSIX) += event_notifier-posix.o + util-obj-$(CONFIG_POSIX) += mmap-alloc.o ++util-obj-$(CONFIG_POSIX) += mmap-file.o + util-obj-$(CONFIG_POSIX) += oslib-posix.o + util-obj-$(CONFIG_POSIX) += qemu-openpty.o + util-obj-$(CONFIG_POSIX) += qemu-thread-posix.o +diff --git a/util/mmap-file.c b/util/mmap-file.c +new file mode 100644 +index 0000000..ce778cf +--- /dev/null ++++ b/util/mmap-file.c +@@ -0,0 +1,153 @@ ++/* ++ * Support for file backed by mmaped host memory. ++ * ++ * Authors: ++ * Rafael David Tinoco <email address hidden> ++ * ++ * This work is licensed under the terms of the GNU GPL, version 2 or ++ * later. See the COPYING file in the top-level directory. ++ */ ++ ++#include "qemu/osdep.h" ++#include "qemu/mmap-file.h" ++ ++static char *qemu_mmap_rand_name(void) ++{ ++ char *name; ++ GRand *rsufix; ++ guint32 sufix; ++ ++ rsufix = g_rand_new(); ++ sufix = g_rand_int(rsufix); ++ g_free(rsufix); ++ name = g_strdup_printf("mmap-%u", sufix); ++ ++ return name; ++} ++ ++static inline void qemu_mmap_rand_name_free(char *str) ++{ ++ g_free(str); ++} ++ ++static bool qemu_mmap_is(const char *path, mode_t what) ++{ ++ struct stat s; ++ ++ memset(&s, 0, sizeof(struct stat)); ++ if (stat(path, &s)) { ++ perror("stat"); ++ goto negative; ++ } ++ ++ if ((s.st_mode & S_IFMT) == what) { ++ return true; ++ } ++ ++negative: ++ return false; ++} ++ ++static inline bool qemu_mmap_is_file(const char *path) ++{ ++ return qemu_mmap_is(path, S_IFREG); ++} ++ ++static inline bool qemu_mmap_is_dir(const char *path) ++{ ++ return qemu_mmap_is(path, S_IFDIR); ++} ++ ++static void *qemu_mmap_alloc_file(const char *filepath, size_t size, int *fd) ++{ ++ void *ptr; ++ int mfd = -1; ++ ++ *fd = -1; ++ ++ mfd = open(filepath, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR); ++ if (mfd == -1) { ++ perror("open"); ++ return NULL; ++ } ++ ++ unlink(filepath); ++ ++ if (ftruncate(mfd, size) == -1) { ++ perror("ftruncate"); ++ close(mfd); ++ return NULL; ++ } ++ ++ ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); ++ if (ptr == MAP_FAILED) { ++ perror("mmap"); ++ close(mfd); ++ return NULL; ++ } ++ ++ *fd = mfd; ++ return ptr; ++} ++ ++static void *qemu_mmap_alloc_dir(const char *dirpath, size_t size, int *fd) ++{ ++ void *ptr; ++ char *file, *rand, *tmp, *dir2use = NULL; ++ ++ if (dirpath && !qemu_mmap_is_dir(dirpath)) { ++ return NULL; ++ } ++ ++ tmp = (char *) g_get_tmp_dir(); ++ dir2use = dirpath ? (char *) dirpath : tmp; ++ rand = qemu_mmap_rand_name(); ++ file = g_strdup_printf("%s/%s", dir2use, rand); ++ ptr = qemu_mmap_alloc_file(file, size, fd); ++ g_free(tmp); ++ qemu_mmap_rand_name_free(rand); ++ ++ return ptr; ++} ++ ++/* ++ * "path" can be: ++ * ++ * filename = full path for the file to back mmap ++ * dir path = full dir path where to create random file for mmap ++ * null = will use <tmpdir> to create random file for mmap ++ */ ++void *qemu_mmap_alloc(const char *path, size_t size, int *fd) ++{ ++ if (!path || qemu_mmap_is_dir(path)) { ++ return qemu_mmap_alloc_dir(path, size, fd); ++ } ++ ++ return qemu_mmap_alloc_file(path, size, fd); ++} ++ ++void qemu_mmap_free(void *ptr, size_t size, int fd) ++{ ++ if (ptr) { ++ munmap(ptr, size); ++ } ++ ++ if (fd != -1) { ++ close(fd); ++ } ++} ++ ++bool qemu_mmap_check(const char *path) ++{ ++ void *ptr; ++ int fd = -1; ++ bool r = true; ++ ++ ptr = qemu_mmap_alloc(path, 4096, &fd); ++ if (!ptr) { ++ r = false; ++ } ++ qemu_mmap_free(ptr, 4096, fd); ++ ++ return r == true ? true : false; ++} +-- +2.9.3 + + + +Commit 31190ed7 added a migration blocker in vhost_dev_init() to +check if memfd would succeed. It is better if this blocker first +checks if vhost backend requires shared log. This will avoid a +situation where a blocker is added inappropriately (e.g. shared +log allocation fails when vhost backend doesn't support it). +--- + hw/virtio/vhost.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index bd051ab..742d0aa 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -1122,7 +1122,7 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && !qemu_memfd_check()) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } +-- +2.9.3 + + + + +> Begin forwarded message: +> +> From: Marc-André Lureau <email address hidden> +> Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter +> Date: October 22, 2016 at 05:18:02 GMT-2 +> To: Rafael David Tinoco <email address hidden> +> Cc: QEMU <email address hidden> +> +> Hi +> +> On Sat, Oct 22, 2016 at 10:01 AM Rafael David Tinoco <<email address hidden> <mailto:<email address hidden>>> wrote: +> Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> check if memfd would succeed. It is better if this blocker first +> checks if vhost backend requires shared log. This will avoid a +> situation where a blocker is added inappropriately (e.g. shared +> log allocation fails when vhost backend doesn't support it). +> +> Could you make this a seperate patch? +> +> Commit: 35f9b6e added a fallback mechanism for systems not supporting +> memfd_create syscall (started being supported since 3.17). +> +> Backporting memfd_create might not be accepted for distros relying +> on older kernels. Nowadays there is no way for security driver +> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> +> Also, because vhost log file descriptors can be passed to other +> processes, after discussion, we thought it is best to back mmap by +> using files that can be placed into a specific directory: this commit +> creates "vhostlog" argv parameter for such purpose. This will allow +> security drivers to operate on those files appropriately. +> +> Argv examples: +> +> -netdev tap,id=net0,vhost=on +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> +> Could it be only a filename? This would simplify testing. +> +> +> For vhost backends supporting shared logs, if vhostlog is non-existent, +> or a directory, random files are going to be created in the specified +> directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> the filepath is always used when allocating vhost log files. +> +> +> Regarding testing, you add utility code mmap-file, could you make this a seperate commit, with unit tests? +> +> thanks +> +> Signed-off-by: Rafael David Tinoco <<email address hidden> <mailto:<email address hidden>>> +> --- +> hw/net/vhost_net.c | 4 +- +> hw/scsi/vhost-scsi.c | 2 +- +> hw/virtio/vhost-vsock.c | 2 +- +> hw/virtio/vhost.c | 41 +++++++------ +> include/hw/virtio/vhost.h | 4 +- +> include/net/vhost_net.h | 1 + +> include/qemu/mmap-file.h | 10 +++ +> net/tap.c | 6 ++ +> qapi-schema.json | 3 + +> qemu-options.hx | 3 +- +> util/Makefile.objs | 1 + +> util/mmap-file.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++ +> 12 files changed, 207 insertions(+), 23 deletions(-) +> create mode 100644 include/qemu/mmap-file.h +> create mode 100644 util/mmap-file.c +> +> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c +> index f2d49ad..d650c92 100644 +> --- a/hw/net/vhost_net.c +> +++ b/hw/net/vhost_net.c +> @@ -171,8 +171,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) +> net->dev.vq_index = net->nc->queue_index * net->dev.nvqs; +> } +> +> - r = vhost_dev_init(&net->dev, options->opaque, +> - options->backend_type, options->busyloop_timeout); +> + r = vhost_dev_init(&net->dev, options->opaque, options->backend_type, +> + options->busyloop_timeout, options->vhostlog); +> if (r < 0) { +> goto fail; +> } +> diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c +> index 5b26946..5dc3d30 100644 +> --- a/hw/scsi/vhost-scsi.c +> +++ b/hw/scsi/vhost-scsi.c +> @@ -248,7 +248,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) +> s->dev.backend_features = 0; +> +> ret = vhost_dev_init(&s->dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg(errp, "vhost-scsi: vhost initialization failed: %s", +> strerror(-ret)); +> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c +> index b481562..6cf6081 100644 +> --- a/hw/virtio/vhost-vsock.c +> +++ b/hw/virtio/vhost-vsock.c +> @@ -342,7 +342,7 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp) +> vsock->vhost_dev.nvqs = ARRAY_SIZE(vsock->vhost_vqs); +> vsock->vhost_dev.vqs = vsock->vhost_vqs; +> ret = vhost_dev_init(&vsock->vhost_dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg_errno(errp, -ret, "vhost-vsock: vhost_dev_init failed"); +> goto err_virtio; +> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +> index bd051ab..d874ebb 100644 +> --- a/hw/virtio/vhost.c +> +++ b/hw/virtio/vhost.c +> @@ -20,7 +20,7 @@ +> #include "qemu/atomic.h" +> #include "qemu/range.h" +> #include "qemu/error-report.h" +> -#include "qemu/memfd.h" +> +#include "qemu/mmap-file.h" +> #include <linux/vhost.h> +> #include "exec/address-spaces.h" +> #include "hw/virtio/virtio-bus.h" +> @@ -326,7 +326,7 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev) +> return log_size; +> } +> +> -static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_alloc(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log; +> uint64_t logsize = size * sizeof(*(log->log)); +> @@ -334,9 +334,7 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +> log = g_new0(struct vhost_log, 1); +> if (share) { +> - log->log = qemu_memfd_alloc("vhost-log", logsize, +> - F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, +> - &fd); +> + log->log = qemu_mmap_alloc(path, logsize, &fd); +> memset(log->log, 0, logsize); +> } else { +> log->log = g_malloc0(logsize); +> @@ -349,12 +347,12 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> return log; +> } +> +> -static struct vhost_log *vhost_log_get(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_get(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log = share ? vhost_log_shm : vhost_log; +> +> if (!log || log->size != size) { +> - log = vhost_log_alloc(size, share); +> + log = vhost_log_alloc(path, size, share); +> if (share) { +> vhost_log_shm = log; +> } else { +> @@ -388,8 +386,7 @@ static void vhost_log_put(struct vhost_dev *dev, bool sync) +> g_free(log->log); +> vhost_log = NULL; +> } else if (vhost_log_shm == log) { +> - qemu_memfd_free(log->log, log->size * sizeof(*(log->log)), +> - log->fd); +> + qemu_mmap_free(log->log, log->size * sizeof(*(log->log)), log->fd); +> vhost_log_shm = NULL; +> } +> +> @@ -405,9 +402,12 @@ static bool vhost_dev_log_is_shared(struct vhost_dev *dev) +> +> static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t size) +> { +> - struct vhost_log *log = vhost_log_get(size, vhost_dev_log_is_shared(dev)); +> - uint64_t log_base = (uintptr_t)log->log; +> int r; +> + struct vhost_log *log; +> + uint64_t log_base; +> + +> + log = vhost_log_get(dev->log_filename, size, vhost_dev_log_is_shared(dev)); +> + log_base = (uintptr_t)log->log; +> +> /* inform backend of log switching, this must be done before +> releasing the current log, to ensure no logging is lost */ +> @@ -1049,7 +1049,8 @@ static void vhost_virtqueue_cleanup(struct vhost_virtqueue *vq) +> } +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> - VhostBackendType backend_type, uint32_t busyloop_timeout) +> + VhostBackendType backend_type, +> + uint32_t busyloop_timeout, char *vhostlog) +> { +> uint64_t features; +> int i, r, n_initialized_vqs = 0; +> @@ -1118,11 +1119,18 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> .priority = 10 +> }; +> +> + hdev->log = NULL; +> + hdev->log_size = 0; +> + hdev->log_enabled = false; +> + hdev->log_filename = vhostlog ? g_strdup(vhostlog) : NULL; +> + g_free(vhostlog); +> + +> if (hdev->migration_blocker == NULL) { +> if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +> - } else if (!qemu_memfd_check()) { +> + } else if (vhost_dev_log_is_shared(hdev) && +> + !qemu_mmap_check(hdev->log_filename)) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: failed to allocate shared memory"); +> } +> @@ -1135,9 +1143,6 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions)); +> hdev->n_mem_sections = 0; +> hdev->mem_sections = NULL; +> - hdev->log = NULL; +> - hdev->log_size = 0; +> - hdev->log_enabled = false; +> hdev->started = false; +> hdev->memory_changed = false; +> memory_listener_register(&hdev->memory_listener, &address_space_memory); +> @@ -1175,6 +1180,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev) +> if (hdev->vhost_ops) { +> hdev->vhost_ops->vhost_backend_cleanup(hdev); +> } +> + g_free(hdev->log_filename); +> assert(!hdev->log); +> +> memset(hdev, 0, sizeof(struct vhost_dev)); +> @@ -1335,7 +1341,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) +> uint64_t log_base; +> +> hdev->log_size = vhost_get_log_size(hdev); +> - hdev->log = vhost_log_get(hdev->log_size, +> + hdev->log = vhost_log_get(hdev->log_filename, +> + hdev->log_size, +> vhost_dev_log_is_shared(hdev)); +> log_base = (uintptr_t)hdev->log->log; +> r = hdev->vhost_ops->vhost_set_log_base(hdev, +> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h +> index e433089..1ea4f3a 100644 +> --- a/include/hw/virtio/vhost.h +> +++ b/include/hw/virtio/vhost.h +> @@ -52,6 +52,7 @@ struct vhost_dev { +> uint64_t max_queues; +> bool started; +> bool log_enabled; +> + char *log_filename; +> uint64_t log_size; +> Error *migration_blocker; +> bool memory_changed; +> @@ -65,7 +66,8 @@ struct vhost_dev { +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> VhostBackendType backend_type, +> - uint32_t busyloop_timeout); +> + uint32_t busyloop_timeout, +> + char *vhostlog); +> void vhost_dev_cleanup(struct vhost_dev *hdev); +> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev); +> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev); +> diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h +> index 5a08eff..94161b2 100644 +> --- a/include/net/vhost_net.h +> +++ b/include/net/vhost_net.h +> @@ -12,6 +12,7 @@ typedef struct VhostNetOptions { +> NetClientState *net_backend; +> uint32_t busyloop_timeout; +> void *opaque; +> + char *vhostlog; +> } VhostNetOptions; +> +> uint64_t vhost_net_get_max_queues(VHostNetState *net); +> diff --git a/include/qemu/mmap-file.h b/include/qemu/mmap-file.h +> new file mode 100644 +> index 0000000..427612a +> --- /dev/null +> +++ b/include/qemu/mmap-file.h +> @@ -0,0 +1,10 @@ +> +#ifndef QEMU_MMAP_FILE_H +> +#define QEMU_MMAP_FILE_H +> + +> +#include "qemu-common.h" +> + +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd); +> +void qemu_mmap_free(void *ptr, size_t size, int fd); +> +bool qemu_mmap_check(const char *path); +> + +> +#endif +> diff --git a/net/tap.c b/net/tap.c +> index b6896a7..7b242cd 100644 +> --- a/net/tap.c +> +++ b/net/tap.c +> @@ -699,6 +699,12 @@ static void net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, +> } +> options.opaque = (void *)(uintptr_t)vhostfd; +> +> + if (tap->has_vhostlog) { +> + options.vhostlog = g_strdup(tap->vhostlog); +> + } else { +> + options.vhostlog = NULL; +> + } +> + +> s->vhost_net = vhost_net_init(&options); +> if (!s->vhost_net) { +> error_setg(errp, +> diff --git a/qapi-schema.json b/qapi-schema.json +> index 5a8ec38..72608bd 100644 +> --- a/qapi-schema.json +> +++ b/qapi-schema.json +> @@ -2640,6 +2640,8 @@ +> # +> # @vhostforce: #optional vhost on for non-MSIX virtio guests +> # +> +# @vhostlog: #optional file or directory for vhost backend log +> +# +> # @queues: #optional number of queues to be created for multiqueue capable tap +> # +> # @poll-us: #optional maximum number of microseconds that could +> @@ -2662,6 +2664,7 @@ +> '*vhostfd': 'str', +> '*vhostfds': 'str', +> '*vhostforce': 'bool', +> + '*vhostlog': 'str', +> '*queues': 'uint32', +> '*poll-us': 'uint32'} } +> +> diff --git a/qemu-options.hx b/qemu-options.hx +> index b1fbdb0..5c09c09 100644 +> --- a/qemu-options.hx +> +++ b/qemu-options.hx +> @@ -1599,7 +1599,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> #else +> "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" +> " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" +> - " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" +> + " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,vhostlog=file|dir][,queues=n]\n" +> " [,poll-us=n]\n" +> " configure a host TAP network backend with ID 'str'\n" +> " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" +> @@ -1618,6 +1618,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> " use vhost=on to enable experimental in kernel accelerator\n" +> " (only has effect for virtio guests which use MSIX)\n" +> " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" +> + " use 'vhostlog=file|dir' file or directory for vhost backend log\n" +> " use 'vhostfd=h' to connect to an already opened vhost net device\n" +> " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" +> " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" +> diff --git a/util/Makefile.objs b/util/Makefile.objs +> index 36c7dcc..69bb27a 100644 +> --- a/util/Makefile.objs +> +++ b/util/Makefile.objs +> @@ -3,6 +3,7 @@ util-obj-y += bufferiszero.o +> util-obj-$(CONFIG_POSIX) += compatfd.o +> util-obj-$(CONFIG_POSIX) += event_notifier-posix.o +> util-obj-$(CONFIG_POSIX) += mmap-alloc.o +> +util-obj-$(CONFIG_POSIX) += mmap-file.o +> util-obj-$(CONFIG_POSIX) += oslib-posix.o +> util-obj-$(CONFIG_POSIX) += qemu-openpty.o +> util-obj-$(CONFIG_POSIX) += qemu-thread-posix.o +> diff --git a/util/mmap-file.c b/util/mmap-file.c +> new file mode 100644 +> index 0000000..ce778cf +> --- /dev/null +> +++ b/util/mmap-file.c +> @@ -0,0 +1,153 @@ +> +/* +> + * Support for file backed by mmaped host memory. +> + * +> + * Authors: +> + * Rafael David Tinoco <<email address hidden> <mailto:<email address hidden>>> +> + * +> + * This work is licensed under the terms of the GNU GPL, version 2 or +> + * later. See the COPYING file in the top-level directory. +> + */ +> + +> +#include "qemu/osdep.h" +> +#include "qemu/mmap-file.h" +> + +> +static char *qemu_mmap_rand_name(void) +> +{ +> + char *name; +> + GRand *rsufix; +> + guint32 sufix; +> + +> + rsufix = g_rand_new(); +> + sufix = g_rand_int(rsufix); +> + g_free(rsufix); +> + name = g_strdup_printf("mmap-%u", sufix); +> + +> + return name; +> +} +> + +> +static inline void qemu_mmap_rand_name_free(char *str) +> +{ +> + g_free(str); +> +} +> + +> +static bool qemu_mmap_is(const char *path, mode_t what) +> +{ +> + struct stat s; +> + +> + memset(&s, 0, sizeof(struct stat)); +> + if (stat(path, &s)) { +> + perror("stat"); +> + goto negative; +> + } +> + +> + if ((s.st_mode & S_IFMT) == what) { +> + return true; +> + } +> + +> +negative: +> + return false; +> +} +> + +> +static inline bool qemu_mmap_is_file(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFREG); +> +} +> + +> +static inline bool qemu_mmap_is_dir(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFDIR); +> +} +> + +> +static void *qemu_mmap_alloc_file(const char *filepath, size_t size, int *fd) +> +{ +> + void *ptr; +> + int mfd = -1; +> + +> + *fd = -1; +> + +> + mfd = open(filepath, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR); +> + if (mfd == -1) { +> + perror("open"); +> + return NULL; +> + } +> + +> + unlink(filepath); +> + +> + if (ftruncate(mfd, size) == -1) { +> + perror("ftruncate"); +> + close(mfd); +> + return NULL; +> + } +> + +> + ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); +> + if (ptr == MAP_FAILED) { +> + perror("mmap"); +> + close(mfd); +> + return NULL; +> + } +> + +> + *fd = mfd; +> + return ptr; +> +} +> + +> +static void *qemu_mmap_alloc_dir(const char *dirpath, size_t size, int *fd) +> +{ +> + void *ptr; +> + char *file, *rand, *tmp, *dir2use = NULL; +> + +> + if (dirpath && !qemu_mmap_is_dir(dirpath)) { +> + return NULL; +> + } +> + +> + tmp = (char *) g_get_tmp_dir(); +> + dir2use = dirpath ? (char *) dirpath : tmp; +> + rand = qemu_mmap_rand_name(); +> + file = g_strdup_printf("%s/%s", dir2use, rand); +> + ptr = qemu_mmap_alloc_file(file, size, fd); +> + g_free(tmp); +> + qemu_mmap_rand_name_free(rand); +> + +> + return ptr; +> +} +> + +> +/* +> + * "path" can be: +> + * +> + * filename = full path for the file to back mmap +> + * dir path = full dir path where to create random file for mmap +> + * null = will use <tmpdir> to create random file for mmap +> + */ +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd) +> +{ +> + if (!path || qemu_mmap_is_dir(path)) { +> + return qemu_mmap_alloc_dir(path, size, fd); +> + } +> + +> + return qemu_mmap_alloc_file(path, size, fd); +> +} +> + +> +void qemu_mmap_free(void *ptr, size_t size, int fd) +> +{ +> + if (ptr) { +> + munmap(ptr, size); +> + } +> + +> + if (fd != -1) { +> + close(fd); +> + } +> +} +> + +> +bool qemu_mmap_check(const char *path) +> +{ +> + void *ptr; +> + int fd = -1; +> + bool r = true; +> + +> + ptr = qemu_mmap_alloc(path, 4096, &fd); +> + if (!ptr) { +> + r = false; +> + } +> + qemu_mmap_free(ptr, 4096, fd); +> + +> + return r == true ? true : false; +> +} +> -- +> 2.9.3 +> +> +> -- +> Marc-André Lureau + + + + + +> Begin forwarded message: +> +> From: Rafael David Tinoco <email address hidden> +> Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter +> Date: October 22, 2016 at 19:52:31 GMT-2 +> To: Marc-André Lureau <email address hidden> +> Cc: Rafael David Tinoco <email address hidden>, qemu-devel <email address hidden> +> +> Hello, +> +>> On Oct 22, 2016, at 05:18, Marc-André Lureau <email address hidden> wrote: +>> +>> Hi +>> +>> On Sat, Oct 22, 2016 at 10:01 AM Rafael David Tinoco <email address hidden> wrote: +>> Commit 31190ed7 added a migration blocker in vhost_dev_init() to +>> check if memfd would succeed. It is better if this blocker first +>> checks if vhost backend requires shared log. This will avoid a +>> situation where a blocker is added inappropriately (e.g. shared +>> log allocation fails when vhost backend doesn't support it). +>> +>> Could you make this a seperate patch? +> +> Just did, in another e-mail, cc'ing you. +> +>> Argv examples: +>> +>> -netdev tap,id=net0,vhost=on +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +>> +>> Could it be only a filename? This would simplify testing. +> +> It could. Should I keep the /tmp/<random> logic if no vhostlog arg is present ? Or you think it should fail if no arg is given ? I'm afraid of backward compatibility when back-porting this to older qemu versions on stable releases (like my case: I'll backport this to ~3 different versions). +> +>> For vhost backends supporting shared logs, if vhostlog is non-existent, +>> or a directory, random files are going to be created in the specified +>> directory (or, for non-existent, in tmpdir). If vhostlog is specified, +>> the filepath is always used when allocating vhost log files. +>> +>> +>> Regarding testing, you add utility code mmap-file, could you make this a seperate commit, with unit tests? +>> +> +> Sure, I'll work on it. +> +>> thanks +> +> Thank u! +> +> -Rafael Tinoco + + + +Commit 31190ed7 added a migration blocker in vhost_dev_init() to +check if memfd would succeed. It is better if this blocker first +checks if vhost backend requires shared log. This will avoid a +situation where a blocker is added inappropriately (e.g. shared +log allocation fails when vhost backend doesn't support it). + +Signed-off-by: Rafael David Tinoco <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +--- + hw/virtio/vhost.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index bd051ab..742d0aa 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -1122,7 +1122,7 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && !qemu_memfd_check()) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } +-- +2.9.3 + + + +On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> check if memfd would succeed. It is better if this blocker first +> checks if vhost backend requires shared log. This will avoid a +> situation where a blocker is added inappropriately (e.g. shared +> log allocation fails when vhost backend doesn't support it). + +Sounds like a bugfix but I'm not sure. Can this part be split +out in a patch by itself? + +> Commit: 35f9b6e added a fallback mechanism for systems not supporting +> memfd_create syscall (started being supported since 3.17). +> +> Backporting memfd_create might not be accepted for distros relying +> on older kernels. Nowadays there is no way for security driver +> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> +> Also, because vhost log file descriptors can be passed to other +> processes, after discussion, we thought it is best to back mmap by +> using files that can be placed into a specific directory: this commit +> creates "vhostlog" argv parameter for such purpose. This will allow +> security drivers to operate on those files appropriately. +> +> Argv examples: +> +> -netdev tap,id=net0,vhost=on +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> +> For vhost backends supporting shared logs, if vhostlog is non-existent, +> or a directory, random files are going to be created in the specified +> directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> the filepath is always used when allocating vhost log files. + +When vhostlog is not specified, can we just use memfd as we did? + +> Signed-off-by: Rafael David Tinoco <email address hidden> +> --- +> hw/net/vhost_net.c | 4 +- +> hw/scsi/vhost-scsi.c | 2 +- +> hw/virtio/vhost-vsock.c | 2 +- +> hw/virtio/vhost.c | 41 +++++++------ +> include/hw/virtio/vhost.h | 4 +- +> include/net/vhost_net.h | 1 + +> include/qemu/mmap-file.h | 10 +++ +> net/tap.c | 6 ++ +> qapi-schema.json | 3 + +> qemu-options.hx | 3 +- +> util/Makefile.objs | 1 + +> util/mmap-file.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++ +> 12 files changed, 207 insertions(+), 23 deletions(-) +> create mode 100644 include/qemu/mmap-file.h +> create mode 100644 util/mmap-file.c +> +> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c +> index f2d49ad..d650c92 100644 +> --- a/hw/net/vhost_net.c +> +++ b/hw/net/vhost_net.c +> @@ -171,8 +171,8 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) +> net->dev.vq_index = net->nc->queue_index * net->dev.nvqs; +> } +> +> - r = vhost_dev_init(&net->dev, options->opaque, +> - options->backend_type, options->busyloop_timeout); +> + r = vhost_dev_init(&net->dev, options->opaque, options->backend_type, +> + options->busyloop_timeout, options->vhostlog); +> if (r < 0) { +> goto fail; +> } +> diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c +> index 5b26946..5dc3d30 100644 +> --- a/hw/scsi/vhost-scsi.c +> +++ b/hw/scsi/vhost-scsi.c +> @@ -248,7 +248,7 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) +> s->dev.backend_features = 0; +> +> ret = vhost_dev_init(&s->dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg(errp, "vhost-scsi: vhost initialization failed: %s", +> strerror(-ret)); +> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c +> index b481562..6cf6081 100644 +> --- a/hw/virtio/vhost-vsock.c +> +++ b/hw/virtio/vhost-vsock.c +> @@ -342,7 +342,7 @@ static void vhost_vsock_device_realize(DeviceState *dev, Error **errp) +> vsock->vhost_dev.nvqs = ARRAY_SIZE(vsock->vhost_vqs); +> vsock->vhost_dev.vqs = vsock->vhost_vqs; +> ret = vhost_dev_init(&vsock->vhost_dev, (void *)(uintptr_t)vhostfd, +> - VHOST_BACKEND_TYPE_KERNEL, 0); +> + VHOST_BACKEND_TYPE_KERNEL, 0, NULL); +> if (ret < 0) { +> error_setg_errno(errp, -ret, "vhost-vsock: vhost_dev_init failed"); +> goto err_virtio; +> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +> index bd051ab..d874ebb 100644 +> --- a/hw/virtio/vhost.c +> +++ b/hw/virtio/vhost.c +> @@ -20,7 +20,7 @@ +> #include "qemu/atomic.h" +> #include "qemu/range.h" +> #include "qemu/error-report.h" +> -#include "qemu/memfd.h" +> +#include "qemu/mmap-file.h" +> #include <linux/vhost.h> +> #include "exec/address-spaces.h" +> #include "hw/virtio/virtio-bus.h" +> @@ -326,7 +326,7 @@ static uint64_t vhost_get_log_size(struct vhost_dev *dev) +> return log_size; +> } +> +> -static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_alloc(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log; +> uint64_t logsize = size * sizeof(*(log->log)); +> @@ -334,9 +334,7 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> +> log = g_new0(struct vhost_log, 1); +> if (share) { +> - log->log = qemu_memfd_alloc("vhost-log", logsize, +> - F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, +> - &fd); +> + log->log = qemu_mmap_alloc(path, logsize, &fd); +> memset(log->log, 0, logsize); +> } else { +> log->log = g_malloc0(logsize); +> @@ -349,12 +347,12 @@ static struct vhost_log *vhost_log_alloc(uint64_t size, bool share) +> return log; +> } +> +> -static struct vhost_log *vhost_log_get(uint64_t size, bool share) +> +static struct vhost_log *vhost_log_get(char *path, uint64_t size, bool share) +> { +> struct vhost_log *log = share ? vhost_log_shm : vhost_log; +> +> if (!log || log->size != size) { +> - log = vhost_log_alloc(size, share); +> + log = vhost_log_alloc(path, size, share); +> if (share) { +> vhost_log_shm = log; +> } else { +> @@ -388,8 +386,7 @@ static void vhost_log_put(struct vhost_dev *dev, bool sync) +> g_free(log->log); +> vhost_log = NULL; +> } else if (vhost_log_shm == log) { +> - qemu_memfd_free(log->log, log->size * sizeof(*(log->log)), +> - log->fd); +> + qemu_mmap_free(log->log, log->size * sizeof(*(log->log)), log->fd); +> vhost_log_shm = NULL; +> } +> +> @@ -405,9 +402,12 @@ static bool vhost_dev_log_is_shared(struct vhost_dev *dev) +> +> static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t size) +> { +> - struct vhost_log *log = vhost_log_get(size, vhost_dev_log_is_shared(dev)); +> - uint64_t log_base = (uintptr_t)log->log; +> int r; +> + struct vhost_log *log; +> + uint64_t log_base; +> + +> + log = vhost_log_get(dev->log_filename, size, vhost_dev_log_is_shared(dev)); +> + log_base = (uintptr_t)log->log; +> +> /* inform backend of log switching, this must be done before +> releasing the current log, to ensure no logging is lost */ +> @@ -1049,7 +1049,8 @@ static void vhost_virtqueue_cleanup(struct vhost_virtqueue *vq) +> } +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> - VhostBackendType backend_type, uint32_t busyloop_timeout) +> + VhostBackendType backend_type, +> + uint32_t busyloop_timeout, char *vhostlog) +> { +> uint64_t features; +> int i, r, n_initialized_vqs = 0; +> @@ -1118,11 +1119,18 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> .priority = 10 +> }; +> +> + hdev->log = NULL; +> + hdev->log_size = 0; +> + hdev->log_enabled = false; +> + hdev->log_filename = vhostlog ? g_strdup(vhostlog) : NULL; +> + g_free(vhostlog); +> + +> if (hdev->migration_blocker == NULL) { +> if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +> - } else if (!qemu_memfd_check()) { +> + } else if (vhost_dev_log_is_shared(hdev) && +> + !qemu_mmap_check(hdev->log_filename)) { +> error_setg(&hdev->migration_blocker, +> "Migration disabled: failed to allocate shared memory"); +> } +> @@ -1135,9 +1143,6 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> hdev->mem = g_malloc0(offsetof(struct vhost_memory, regions)); +> hdev->n_mem_sections = 0; +> hdev->mem_sections = NULL; +> - hdev->log = NULL; +> - hdev->log_size = 0; +> - hdev->log_enabled = false; +> hdev->started = false; +> hdev->memory_changed = false; +> memory_listener_register(&hdev->memory_listener, &address_space_memory); +> @@ -1175,6 +1180,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev) +> if (hdev->vhost_ops) { +> hdev->vhost_ops->vhost_backend_cleanup(hdev); +> } +> + g_free(hdev->log_filename); +> assert(!hdev->log); +> +> memset(hdev, 0, sizeof(struct vhost_dev)); +> @@ -1335,7 +1341,8 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) +> uint64_t log_base; +> +> hdev->log_size = vhost_get_log_size(hdev); +> - hdev->log = vhost_log_get(hdev->log_size, +> + hdev->log = vhost_log_get(hdev->log_filename, +> + hdev->log_size, +> vhost_dev_log_is_shared(hdev)); +> log_base = (uintptr_t)hdev->log->log; +> r = hdev->vhost_ops->vhost_set_log_base(hdev, +> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h +> index e433089..1ea4f3a 100644 +> --- a/include/hw/virtio/vhost.h +> +++ b/include/hw/virtio/vhost.h +> @@ -52,6 +52,7 @@ struct vhost_dev { +> uint64_t max_queues; +> bool started; +> bool log_enabled; +> + char *log_filename; +> uint64_t log_size; +> Error *migration_blocker; +> bool memory_changed; +> @@ -65,7 +66,8 @@ struct vhost_dev { +> +> int vhost_dev_init(struct vhost_dev *hdev, void *opaque, +> VhostBackendType backend_type, +> - uint32_t busyloop_timeout); +> + uint32_t busyloop_timeout, +> + char *vhostlog); +> void vhost_dev_cleanup(struct vhost_dev *hdev); +> int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev); +> void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev); +> diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h +> index 5a08eff..94161b2 100644 +> --- a/include/net/vhost_net.h +> +++ b/include/net/vhost_net.h +> @@ -12,6 +12,7 @@ typedef struct VhostNetOptions { +> NetClientState *net_backend; +> uint32_t busyloop_timeout; +> void *opaque; +> + char *vhostlog; +> } VhostNetOptions; +> +> uint64_t vhost_net_get_max_queues(VHostNetState *net); +> diff --git a/include/qemu/mmap-file.h b/include/qemu/mmap-file.h +> new file mode 100644 +> index 0000000..427612a +> --- /dev/null +> +++ b/include/qemu/mmap-file.h +> @@ -0,0 +1,10 @@ +> +#ifndef QEMU_MMAP_FILE_H +> +#define QEMU_MMAP_FILE_H +> + +> +#include "qemu-common.h" +> + +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd); +> +void qemu_mmap_free(void *ptr, size_t size, int fd); +> +bool qemu_mmap_check(const char *path); +> + +> +#endif +> diff --git a/net/tap.c b/net/tap.c +> index b6896a7..7b242cd 100644 +> --- a/net/tap.c +> +++ b/net/tap.c +> @@ -699,6 +699,12 @@ static void net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, +> } +> options.opaque = (void *)(uintptr_t)vhostfd; +> +> + if (tap->has_vhostlog) { +> + options.vhostlog = g_strdup(tap->vhostlog); +> + } else { +> + options.vhostlog = NULL; +> + } +> + +> s->vhost_net = vhost_net_init(&options); +> if (!s->vhost_net) { +> error_setg(errp, +> diff --git a/qapi-schema.json b/qapi-schema.json +> index 5a8ec38..72608bd 100644 +> --- a/qapi-schema.json +> +++ b/qapi-schema.json +> @@ -2640,6 +2640,8 @@ +> # +> # @vhostforce: #optional vhost on for non-MSIX virtio guests +> # +> +# @vhostlog: #optional file or directory for vhost backend log +> +# +> # @queues: #optional number of queues to be created for multiqueue capable tap +> # +> # @poll-us: #optional maximum number of microseconds that could +> @@ -2662,6 +2664,7 @@ +> '*vhostfd': 'str', +> '*vhostfds': 'str', +> '*vhostforce': 'bool', +> + '*vhostlog': 'str', +> '*queues': 'uint32', +> '*poll-us': 'uint32'} } +> +> diff --git a/qemu-options.hx b/qemu-options.hx +> index b1fbdb0..5c09c09 100644 +> --- a/qemu-options.hx +> +++ b/qemu-options.hx +> @@ -1599,7 +1599,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> #else +> "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" +> " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" +> - " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" +> + " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,vhostlog=file|dir][,queues=n]\n" +> " [,poll-us=n]\n" +> " configure a host TAP network backend with ID 'str'\n" +> " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" +> @@ -1618,6 +1618,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, +> " use vhost=on to enable experimental in kernel accelerator\n" +> " (only has effect for virtio guests which use MSIX)\n" +> " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" +> + " use 'vhostlog=file|dir' file or directory for vhost backend log\n" +> " use 'vhostfd=h' to connect to an already opened vhost net device\n" +> " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" +> " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" +> diff --git a/util/Makefile.objs b/util/Makefile.objs +> index 36c7dcc..69bb27a 100644 +> --- a/util/Makefile.objs +> +++ b/util/Makefile.objs +> @@ -3,6 +3,7 @@ util-obj-y += bufferiszero.o +> util-obj-$(CONFIG_POSIX) += compatfd.o +> util-obj-$(CONFIG_POSIX) += event_notifier-posix.o +> util-obj-$(CONFIG_POSIX) += mmap-alloc.o +> +util-obj-$(CONFIG_POSIX) += mmap-file.o +> util-obj-$(CONFIG_POSIX) += oslib-posix.o +> util-obj-$(CONFIG_POSIX) += qemu-openpty.o +> util-obj-$(CONFIG_POSIX) += qemu-thread-posix.o +> diff --git a/util/mmap-file.c b/util/mmap-file.c +> new file mode 100644 +> index 0000000..ce778cf +> --- /dev/null +> +++ b/util/mmap-file.c +> @@ -0,0 +1,153 @@ +> +/* +> + * Support for file backed by mmaped host memory. +> + * +> + * Authors: +> + * Rafael David Tinoco <email address hidden> +> + * +> + * This work is licensed under the terms of the GNU GPL, version 2 or +> + * later. See the COPYING file in the top-level directory. +> + */ +> + +> +#include "qemu/osdep.h" +> +#include "qemu/mmap-file.h" +> + +> +static char *qemu_mmap_rand_name(void) +> +{ +> + char *name; +> + GRand *rsufix; +> + guint32 sufix; +> + +> + rsufix = g_rand_new(); +> + sufix = g_rand_int(rsufix); +> + g_free(rsufix); +> + name = g_strdup_printf("mmap-%u", sufix); +> + +> + return name; +> +} +> + +> +static inline void qemu_mmap_rand_name_free(char *str) +> +{ +> + g_free(str); +> +} +> + +> +static bool qemu_mmap_is(const char *path, mode_t what) +> +{ +> + struct stat s; +> + +> + memset(&s, 0, sizeof(struct stat)); +> + if (stat(path, &s)) { +> + perror("stat"); +> + goto negative; +> + } +> + +> + if ((s.st_mode & S_IFMT) == what) { +> + return true; +> + } +> + +> +negative: +> + return false; +> +} +> + +> +static inline bool qemu_mmap_is_file(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFREG); +> +} +> + +> +static inline bool qemu_mmap_is_dir(const char *path) +> +{ +> + return qemu_mmap_is(path, S_IFDIR); +> +} +> + +> +static void *qemu_mmap_alloc_file(const char *filepath, size_t size, int *fd) +> +{ +> + void *ptr; +> + int mfd = -1; +> + +> + *fd = -1; +> + +> + mfd = open(filepath, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR); +> + if (mfd == -1) { +> + perror("open"); +> + return NULL; +> + } +> + +> + unlink(filepath); +> + +> + if (ftruncate(mfd, size) == -1) { +> + perror("ftruncate"); +> + close(mfd); +> + return NULL; +> + } +> + +> + ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); +> + if (ptr == MAP_FAILED) { +> + perror("mmap"); +> + close(mfd); +> + return NULL; +> + } +> + +> + *fd = mfd; +> + return ptr; +> +} +> + +> +static void *qemu_mmap_alloc_dir(const char *dirpath, size_t size, int *fd) +> +{ +> + void *ptr; +> + char *file, *rand, *tmp, *dir2use = NULL; +> + +> + if (dirpath && !qemu_mmap_is_dir(dirpath)) { +> + return NULL; +> + } +> + +> + tmp = (char *) g_get_tmp_dir(); +> + dir2use = dirpath ? (char *) dirpath : tmp; +> + rand = qemu_mmap_rand_name(); +> + file = g_strdup_printf("%s/%s", dir2use, rand); +> + ptr = qemu_mmap_alloc_file(file, size, fd); +> + g_free(tmp); +> + qemu_mmap_rand_name_free(rand); +> + +> + return ptr; +> +} +> + +> +/* +> + * "path" can be: +> + * +> + * filename = full path for the file to back mmap +> + * dir path = full dir path where to create random file for mmap +> + * null = will use <tmpdir> to create random file for mmap +> + */ +> +void *qemu_mmap_alloc(const char *path, size_t size, int *fd) +> +{ +> + if (!path || qemu_mmap_is_dir(path)) { +> + return qemu_mmap_alloc_dir(path, size, fd); +> + } +> + +> + return qemu_mmap_alloc_file(path, size, fd); +> +} +> + +> +void qemu_mmap_free(void *ptr, size_t size, int fd) +> +{ +> + if (ptr) { +> + munmap(ptr, size); +> + } +> + +> + if (fd != -1) { +> + close(fd); +> + } +> +} +> + +> +bool qemu_mmap_check(const char *path) +> +{ +> + void *ptr; +> + int fd = -1; +> + bool r = true; +> + +> + ptr = qemu_mmap_alloc(path, 4096, &fd); +> + if (!ptr) { +> + r = false; +> + } +> + qemu_mmap_free(ptr, 4096, fd); +> + +> + return r == true ? true : false; +> +} +> -- +> 2.9.3 + + +On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> wrote: +> +> On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> > check if memfd would succeed. It is better if this blocker first +> > checks if vhost backend requires shared log. This will avoid a +> > situation where a blocker is added inappropriately (e.g. shared +> > log allocation fails when vhost backend doesn't support it). +> +> Sounds like a bugfix but I'm not sure. Can this part be split +> out in a patch by itself? + +Already sent some days ago (and pointed by Marc today). + +> > Commit: 35f9b6e added a fallback mechanism for systems not supporting +> > memfd_create syscall (started being supported since 3.17). +> > +> > Backporting memfd_create might not be accepted for distros relying +> > on older kernels. Nowadays there is no way for security driver +> > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> > +> > Also, because vhost log file descriptors can be passed to other +> > processes, after discussion, we thought it is best to back mmap by +> > using files that can be placed into a specific directory: this commit +> > creates "vhostlog" argv parameter for such purpose. This will allow +> > security drivers to operate on those files appropriately. +> > +> > Argv examples: +> > +> > -netdev tap,id=net0,vhost=on +> > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> > +> > For vhost backends supporting shared logs, if vhostlog is non-existent, +> > or a directory, random files are going to be created in the specified +> > directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> > the filepath is always used when allocating vhost log files. +> +> When vhostlog is not specified, can we just use memfd as we did? +> + +This was my approach on a "pastebin" example before this patch (in the +discussion thread we had). Problem goes back to when vhost log file +descriptor is shared with some vhost-user implementation - like the +interface allows to - and the security driver labelling issue. IMO, +yes, we could let vhostlog to specify a log file, and, if not +specified, assume memfd is ok to be used. + +Please let me know if you - and Marc - want me to keep using memfd. +I'll create the mmap-file tests and files in a different commit, like +Marc has asked for, and will propose the patch again by the end of +this week. + + +On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: +> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> wrote: +> > +> > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> > > check if memfd would succeed. It is better if this blocker first +> > > checks if vhost backend requires shared log. This will avoid a +> > > situation where a blocker is added inappropriately (e.g. shared +> > > log allocation fails when vhost backend doesn't support it). +> > +> > Sounds like a bugfix but I'm not sure. Can this part be split +> > out in a patch by itself? +> +> Already sent some days ago (and pointed by Marc today). +> +> > > Commit: 35f9b6e added a fallback mechanism for systems not supporting +> > > memfd_create syscall (started being supported since 3.17). +> > > +> > > Backporting memfd_create might not be accepted for distros relying +> > > on older kernels. Nowadays there is no way for security driver +> > > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> > > +> > > Also, because vhost log file descriptors can be passed to other +> > > processes, after discussion, we thought it is best to back mmap by +> > > using files that can be placed into a specific directory: this commit +> > > creates "vhostlog" argv parameter for such purpose. This will allow +> > > security drivers to operate on those files appropriately. +> > > +> > > Argv examples: +> > > +> > > -netdev tap,id=net0,vhost=on +> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> > > +> > > For vhost backends supporting shared logs, if vhostlog is non-existent, +> > > or a directory, random files are going to be created in the specified +> > > directory (or, for non-existent, in tmpdir). If vhostlog is specified, +> > > the filepath is always used when allocating vhost log files. +> > +> > When vhostlog is not specified, can we just use memfd as we did? +> > +> +> This was my approach on a "pastebin" example before this patch (in the +> discussion thread we had). Problem goes back to when vhost log file +> descriptor is shared with some vhost-user implementation - like the +> interface allows to - and the security driver labelling issue. IMO, +> yes, we could let vhostlog to specify a log file, and, if not +> specified, assume memfd is ok to be used. +> +> Please let me know if you - and Marc - want me to keep using memfd. +> I'll create the mmap-file tests and files in a different commit, like +> Marc has asked for, and will propose the patch again by the end of +> this week. + +I think that the best approach is to allow passing in the fd, +not the file path. If not passed, use memfd. + +-- +MST + + +Hello Michael, André, + +Could you do a quick review before a final submission ? + +http://paste.ubuntu.com/23446279/ + +- I split the commits into 1) bugfix, 2) new util with test, 3) vhostlog + +The unit test is testing passing fds between 2 processes and asserting +contents of mmap buffer coming from the "vhostlog" util (mmap-file). + +Your final comment on the "vhostlog" was: + +>> Argv examples: +>> +>> -netdev tap,id=net0,vhost=on +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +>> -netdev tap,id=net0,vhost=on,vhostlog=/tmp + +(André) > Could it be only a filename? This would simplify testing. +(Michael) > When vhostlog is not specified, can we just use memfd as we did? + +I'm going to change this to: + +1 - if vhostlog is not provided shared log can't be used. Use memfd. + +2 - for shared logs, vhostlog has to be provided as a "file" ? + +Should i keep vhostlog being a directory also ? (i know we are unlinking the +file so might not be needed BUT a static file might have a race condition in +between different instances and providing a directory - that creates random +files on it - might be better approach). + +Is there anything else ? + +Thank you + +Rafael Tinoco + +On Mon, Oct 31, 2016 at 8:30 PM, Michael S. Tsirkin <email address hidden> wrote: +> On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: +>> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> wrote: +>> > +>> > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +>> > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +>> > > check if memfd would succeed. It is better if this blocker first +>> > > checks if vhost backend requires shared log. This will avoid a +>> > > situation where a blocker is added inappropriately (e.g. shared +>> > > log allocation fails when vhost backend doesn't support it). +>> > +>> > Sounds like a bugfix but I'm not sure. Can this part be split +>> > out in a patch by itself? +>> +>> Already sent some days ago (and pointed by Marc today). +>> +>> > > Commit: 35f9b6e added a fallback mechanism for systems not supporting +>> > > memfd_create syscall (started being supported since 3.17). +>> > > +>> > > Backporting memfd_create might not be accepted for distros relying +>> > > on older kernels. Nowadays there is no way for security driver +>> > > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +>> > > +>> > > Also, because vhost log file descriptors can be passed to other +>> > > processes, after discussion, we thought it is best to back mmap by +>> > > using files that can be placed into a specific directory: this commit +>> > > creates "vhostlog" argv parameter for such purpose. This will allow +>> > > security drivers to operate on those files appropriately. +>> > > +>> > > Argv examples: +>> > > +>> > > -netdev tap,id=net0,vhost=on +>> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +>> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +>> > > +>> > > For vhost backends supporting shared logs, if vhostlog is non-existent, +>> > > or a directory, random files are going to be created in the specified +>> > > directory (or, for non-existent, in tmpdir). If vhostlog is specified, +>> > > the filepath is always used when allocating vhost log files. +>> > +>> > When vhostlog is not specified, can we just use memfd as we did? +>> > +>> +>> This was my approach on a "pastebin" example before this patch (in the +>> discussion thread we had). Problem goes back to when vhost log file +>> descriptor is shared with some vhost-user implementation - like the +>> interface allows to - and the security driver labelling issue. IMO, +>> yes, we could let vhostlog to specify a log file, and, if not +>> specified, assume memfd is ok to be used. +>> +>> Please let me know if you - and Marc - want me to keep using memfd. +>> I'll create the mmap-file tests and files in a different commit, like +>> Marc has asked for, and will propose the patch again by the end of +>> this week. +> +> I think that the best approach is to allow passing in the fd, +> not the file path. If not passed, use memfd. +> +> -- +> MST + + +Hi + +On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco < +<email address hidden>> wrote: + +> Hello Michael, André, +> +> Could you do a quick review before a final submission ? +> +> http://paste.ubuntu.com/23446279/ +> +> - I split the commits into 1) bugfix, 2) new util with test, 3) vhostlog +> +> The unit test is testing passing fds between 2 processes and asserting +> contents of mmap buffer coming from the "vhostlog" util (mmap-file). +> +> Your final comment on the "vhostlog" was: +> +> >> Argv examples: +> >> +> >> -netdev tap,id=net0,vhost=on +> >> -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> >> -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> +> (André) > Could it be only a filename? This would simplify testing. +> (Michael) > When vhostlog is not specified, can we just use memfd as we +> did? +> +> +Michael said: +https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg08197.html +I think that the best approach is to allow passing in the fd, not the file +path. If not passed, use memfd. + +I do agree :) + +I'm going to change this to: +> +> 1 - if vhostlog is not provided shared log can't be used. Use memfd. +> +> 2 - for shared logs, vhostlog has to be provided as a "file" ? +> +> Should i keep vhostlog being a directory also ? (i know we are unlinking +> the +> file so might not be needed BUT a static file might have a race condition +> in +> between different instances and providing a directory - that creates random +> files on it - might be better approach). +> +> Is there anything else ? +> + +Do we really need to give a path? (pass fd with -add-fd/qmp add-fd) + +Thank you +> +> Rafael Tinoco +> +> On Mon, Oct 31, 2016 at 8:30 PM, Michael S. Tsirkin <email address hidden> +> wrote: +> > On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: +> >> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <email address hidden> +> wrote: +> >> > +> >> > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: +> >> > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to +> >> > > check if memfd would succeed. It is better if this blocker first +> >> > > checks if vhost backend requires shared log. This will avoid a +> >> > > situation where a blocker is added inappropriately (e.g. shared +> >> > > log allocation fails when vhost backend doesn't support it). +> >> > +> >> > Sounds like a bugfix but I'm not sure. Can this part be split +> >> > out in a patch by itself? +> >> +> >> Already sent some days ago (and pointed by Marc today). +> >> +> >> > > Commit: 35f9b6e added a fallback mechanism for systems not +> supporting +> >> > > memfd_create syscall (started being supported since 3.17). +> >> > > +> >> > > Backporting memfd_create might not be accepted for distros relying +> >> > > on older kernels. Nowadays there is no way for security driver +> >> > > to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX. +> >> > > +> >> > > Also, because vhost log file descriptors can be passed to other +> >> > > processes, after discussion, we thought it is best to back mmap by +> >> > > using files that can be placed into a specific directory: this +> commit +> >> > > creates "vhostlog" argv parameter for such purpose. This will allow +> >> > > security drivers to operate on those files appropriately. +> >> > > +> >> > > Argv examples: +> >> > > +> >> > > -netdev tap,id=net0,vhost=on +> >> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp/guest.log +> >> > > -netdev tap,id=net0,vhost=on,vhostlog=/tmp +> >> > > +> >> > > For vhost backends supporting shared logs, if vhostlog is +> non-existent, +> >> > > or a directory, random files are going to be created in the +> specified +> >> > > directory (or, for non-existent, in tmpdir). If vhostlog is +> specified, +> >> > > the filepath is always used when allocating vhost log files. +> >> > +> >> > When vhostlog is not specified, can we just use memfd as we did? +> >> > +> >> +> >> This was my approach on a "pastebin" example before this patch (in the +> >> discussion thread we had). Problem goes back to when vhost log file +> >> descriptor is shared with some vhost-user implementation - like the +> >> interface allows to - and the security driver labelling issue. IMO, +> >> yes, we could let vhostlog to specify a log file, and, if not +> >> specified, assume memfd is ok to be used. +> >> +> >> Please let me know if you - and Marc - want me to keep using memfd. +> >> I'll create the mmap-file tests and files in a different commit, like +> >> Marc has asked for, and will propose the patch again by the end of +> >> this week. +> > +> > I think that the best approach is to allow passing in the fd, +> > not the file path. If not passed, use memfd. +> > +> > -- +> > MST +> +> -- +Marc-André Lureau + + +Hello, + +> On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco <email address hidden> wrote: +> Hello Michael, André, +> +> Could you do a quick review before a final submission ? +> +> http://paste.ubuntu.com/23446279/ +> ... +> (André) > Could it be only a filename? This would simplify testing. +> (Michael) > When vhostlog is not specified, can we just use memfd as we did? +> +> Michael said: https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg08197.html +> I think that the best approach is to allow passing in the fd, not the file path. If not passed, use memfd. + +Missed this one. + +> I do agree :) + +Sounds good. I see that the new approach is to let the managing library to create the files and just pass the file descriptors, this way security rules are applied to library itself and not to qemu processes. + +> Do we really need to give a path? (pass fd with -add-fd/qmp add-fd) + +I guess not. So, for shared logs: + +- vhostlogfd has to be provided. +- if vhostlogfd is not provided, use memfd. +(we don't want writes in /tmp, should i remove fallback mechanism from memfd logic) +- if memfd fails, log can't be shared/created and there is a migration blocker. + +André, Michael, + +I'll work on that and get the patches soon, meanwhile, could u push: + +- "vhost: migration blocker only if shared log is use" + +so I can backport it to Debian ? + +Thank you, +-Rafael Tinoco + +For Ubuntu Xenial (Mitaka), Yakkety (Newton), Zesty: Commit 0d34fbabc1 fixes the issue for vhost-net kernel. Vhost-net kernel doesn't use shared log so the verification is not used and apparmor profiles won't block the live migration. With customers using vhost-user that might still cause migration problems, but, likely, those are the vast minority. + +commit 0d34fbabc13891da41582b0823867dc5733fffef +Author: Rafael David Tinoco <email address hidden> +Date: Mon Oct 24 15:35:03 2016 +0000 + + vhost: migration blocker only if shared log is used + + Commit 31190ed7 added a migration blocker in vhost_dev_init() to + check if memfd would succeed. It is better if this blocker first + checks if vhost backend requires shared log. This will avoid a + situation where a blocker is added inappropriately (e.g. shared + log allocation fails when vhost backend doesn't support it). + + Signed-off-by: Rafael David Tinoco <email address hidden> + Reviewed-by: Marc-André Lureau <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + +diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c +index 131f164..25bf67f 100644 +--- a/hw/virtio/vhost.c ++++ b/hw/virtio/vhost.c +@@ -1122,7 +1122,7 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque, + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) { + error_setg(&hdev->migration_blocker, + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."); +- } else if (!qemu_memfd_check()) { ++ } else if (vhost_dev_log_is_shared(hdev) && !qemu_memfd_check()) { + error_setg(&hdev->migration_blocker, + "Migration disabled: failed to allocate shared memory"); + } + +The "final" fix for upstream fix is being finished by me, but, might not be suitable for SRU since it will add features in qemu (and likely to libvirt) in order for the vhost log file to be passed (by using an already opened file descriptor). This will require changes in libvirt and nova-compute but this change will, finally, allow security driver to apply rules to vhost log file for shared logs (mostly for vhost-user drivers). + +On Fri, Nov 18, 2016 at 11:21 AM, Rafael David Tinoco < +<email address hidden>> wrote: + +> With customers using vhost-user that might +> still cause migration problems, but, likely, those are the vast +> minority. +> + +It is and has migration issues in general atm anyway - see: +https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03026.html +https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg03223.html + +So that needs more work and is not in your current scope IMHO. + + +Thanks Christian, + +Then I'll finish this SRU first. Will work in the vhost mmap log file right after. + + + +Took some more time here because of LP: #1621269. + +Right now Zesty is behind Yakkety because of a Security Update. Not sure you need me to attach a debdiff for Zesty as well. Let me know. + +On Tue, Nov 22, 2016 at 1:02 PM, Rafael David Tinoco < +<email address hidden>> wrote: + +> Right now Zesty is behind Yakkety because of a Security Update. Not sure +> you need me to attach a debdiff for Zesty as well. Let me know. +> + +Arr - bad timing It got an upload about 5 minutes ago. +So yes a Zesty debdiff would be nice. + +-- +Christian Ehrhardt +Software Engineer, Ubuntu Server +Canonical Ltd + + + + +Thanks Rafael - the upstream work on this is excellent! + +I already built all those fine and I'm now looking into some regression checks before considering/doing an upload to Dev-Release & SRU-queue + +Some other stages of my extra tests are currently WIP, but those that work worked fine on the ppa I built of your debdiffs. + +That covers: +- migration with various workloads +- different types of migrations (live, offline, postcopy) +- upgrading onto the new qemu version +- migration into the upgraded version + +I'll attach the log and upload your changes, thanks for your work. +I see you already set the SRU Teamplate for the SRU Team to review then - thanks. + + + +Uploaded into Zesty - per SRU policy (and experience that always something happens at the last minute at LP build/tests) waiting with the SRU uploads until that fully migrated. + +This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu7 + +--------------- +qemu (1:2.6.1+dfsg-0ubuntu7) zesty; urgency=medium + + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 13:45:52 +0100 + +Ok, update into Zesty has passed and you already supplied the SRU Template. +Uploaded to Xenial and Yakkety queues for the SRU Team to consider your Fix. + +Hello Rafael, or anyone else affected, + +Accepted qemu into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.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, 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! + +Commit 0d34fbabc13 is upstream, so setting this to "Fix committed", too. + + +This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu7~cloud0 +--------------- + + qemu (1:2.6.1+dfsg-0ubuntu7~cloud0) xenial-ocata; urgency=medium + . + * New update for the Ubuntu Cloud Archive. + . + qemu (1:2.6.1+dfsg-0ubuntu7) zesty; urgency=medium + . + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + +Hello Rafael, or anyone else affected, + +Accepted qemu into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.6.1+dfsg-0ubuntu5.2 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! + +Hi all, + +I am facing this issue too, and although I can confirm the patch can be easily backported to Trusty (we run Mitaka on Trusty), some of our customers have VMs started with the old qemu and I cannot live migrate anymore or update qemu without stopping and starting the VM. + +Do you have any suggestion on how to allow the live migration of VMs currently running with qemu pre-patch and kernel 3.13? + +Thank you in advance + +Hello Antonio (@arcimboldo) + +The fix only makes sense for newer QEMUs (>= Xenial, like the one from Mitaka Ubuntu Cloud Archive). + +OBS: + +The "migration check" is done in VHOST initialization functions when the devices are virtually attached to the virtual machine. If you are using kernel 3.13 and have apparmor enabled, then all the running instances have the "migration blocker" ON - because of this buggy migration check - and won't be able to live migration. + +Unfortunately there is a "in-memory" linked list telling qemu that is has a blocker (with the reason). This blocker was added during instance startup and will be checked/used only when instance is live-migrated. + +Check this: http://pastebin.ubuntu.com/23517175/ + +If you started the instance in a host not running apparmor (or not having libvirt profile loaded, for example) it won't block the creation of /tmp/memfd-XXX files during instance initialization. That won't trigger the "blocker flag" inside the running program and, if/when needed, the live migration will be able to occur. + +This means that, after installing the new package, if you're using apparmor, yes, you would have to RESTART running instances that were affected by this bug in order to live migrating them. Sorry for the bad news! Even if you remove the apparmor rules, the migration blocker is already set. + +Hacking your process virtual memory would jeopardize the contents of the virtual memory (could be catastrophic specially for a virtual machine). + + +@jamespage, @cpaelzer, + +I'll verify this fix in couple of days so it can be released. + +Thank you! + +Rafael + +Xenial Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel is needed). This verifies that Ubuntu Cloud Archive repositories will be alright with this new packages (from Xenial / Yakkety). + +## CURRENT + +inaddy@(xkvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.5+dfsg-5ubuntu10.6 + Candidate: 1:2.5+dfsg-5ubuntu10.6 + +xkvm01 (sender): + +Jan 11 01:07:54 xkvm01 kernel: type=1400 audit(1484104074.014:13): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-Jh5UhR" pid=2535 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=112 ouid=112 + +$ sudo virsh migrate --live guest qemu+ssh://xkvm02/system +error: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +xkvm02 (receiver): + +Jan 11 01:08:23 xkvm02 kernel: type=1400 audit(1484104103.888:53): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-fc9rij" pid=2000 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=112 ouid=112 + +OBS: The check was being done in the wrong place AND situation, like I showed in this bug. + +## PROPOSED + + +inaddy@(xkvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.5+dfsg-5ubuntu10.7 + Candidate: 1:2.5+dfsg-5ubuntu10.7 + +xkvm01 (sender): + +<nothing related to /tmp/memfd> + +xkvm02 (receiver): + +inaddy@(xkvm02):~$ virsh list + Id Name State +---------------------------------------------------- + 1 guest running + +<nothing related to /tmp/memfd> + +Its all good. + +verification-xenial-done + +Yakkety Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel is needed). This verifies that Ubuntu Cloud Archive repositories will be alright with this new packages (from Xenial / Yakkety). + +## CURRENT + +inaddy@(ykvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.6.1+dfsg-0ubuntu5.1 + Candidate: 1:2.6.1+dfsg-0ubuntu5.1 + +ykvm01 (sender): + +Jan 11 11:34:35 ykvm01 kernel: type=1400 audit(1484141675.962:53): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-bF8new" pid=1934 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=111 ouid=111 + +inaddy@(ykvm01):~$ sudo virsh migrate --live guest qemu+ssh://ykvm02/system +error: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory + +ykvm02 (receiver): + +Jan 11 11:39:31 ykvm02 kernel: type=1400 audit(1484141971.526:53): apparmor="DENIED" operation="mknod" profile="libvirt-7cdcb6c0-f85e-4639-912b-c785bd5992d9" name="/tmp/memfd-JZ6L9T" pid=2177 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=111 ouid=111 + +OBS: The check was being done in the wrong place AND situation, like I showed in this bug. + + + +## PROPOSED + +inaddy@(ykvm01):~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:2.6.1+dfsg-0ubuntu5.2 + Candidate: 1:2.6.1+dfsg-0ubuntu5.2 + +ykvm01 (sender): + +<nothing related to /tmp/memfd> + +ykvm02 (receiver): + +inaddy@(ykvm02):~$ virsh list + Id Name State +---------------------------------------------------- + 1 guest running + +<nothing related to /tmp/memfd> + +Its all good. + +verification-yakkety-done + +Commit 0d34fbabc13 has been released with QEMU v2.8 + +This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu5.2 + +--------------- +qemu (1:2.6.1+dfsg-0ubuntu5.2) yakkety; urgency=medium + + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 13:45:46 +0100 + +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. + +Ping - we have the next fix for Xenial in the queue - all others are released now, has this one "baked" enough for Xenial SRU to migrate? + +For me we had enough tests already. Upstream development/tests, Zesty, Yakkety. Christian, could you please move Xenial for me ? I have some end users waiting for this. Thank you very much. + +On Tue, Jan 24, 2017 at 1:52 AM, Rafael David Tinoco < +<email address hidden>> wrote: + +> Christian, could you please move Xenial for me ? I have some +> end users waiting for this. Thank you very much. +> + +I can't - IIRC that is up to the SRU Team, I pinged the #ubuntu-release +channel if one could take a look. +You could do so again today if you want. + + +Thanks Christian! Will do!! + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.7 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.7) xenial; urgency=medium + + [ Rafael David Tinoco ] + * Fixed wrong migration blocker when vhost is used (LP: #1626972) + - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch + + -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 13:45:39 +0100 + +For Mitaka, this bug will be included in UCA together with the fix for: + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1656480 + +When it becomes available. + diff --git a/results/classifier/105/KVM/1635339 b/results/classifier/105/KVM/1635339 new file mode 100644 index 00000000..4733f6e9 --- /dev/null +++ b/results/classifier/105/KVM/1635339 @@ -0,0 +1,826 @@ +KVM: 0.588 +vnc: 0.506 +mistranslation: 0.486 +other: 0.423 +boot: 0.380 +device: 0.378 +network: 0.314 +assembly: 0.311 +instruction: 0.307 +semantic: 0.302 +socket: 0.287 +graphic: 0.282 + +qxl_pre_save assertion failure on vm "save" + +When I try and save my Windows 10 VM, I see an assertion failure, and the machine is shut down. + +I see the following in the log: + +main_channel_handle_parsed: agent start +qemu-system-x86_64: /build/qemu-Zwynhi/qemu-2.5+dfsg/hw/display/qxl.c:2101: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. +2016-10-20 11:52:42.713+0000: shutting down + +Please let me know what other information would be relevant! + +Hmm docmax on #qemu just complained about a similar error; although they were on win2016, and using qemu-2.7 and the latest git versions, and that assert has been in there for years. + +Can you please add the full qemu command line you're using, and the version of the spice/qxl drivers you're using inside the windows VM. + + +QXL driver version is 17.54.59.923 + +Commandline (git compiled today) is: + +/usr/sbin/qemu-system-x86_64 -name guest=dc,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-dc/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Haswell-noTSX,+vme,+ds,+acpi,+ss,+ht,+tm,+pbe,+dtes64,+monitor,+ds_cpl,+vmx,+est,+tm2,+xtpr,+pdcm,+osxsave,+f16c,+rdrand,+arat,+tsc_adjust,+xsaveopt,+pdpe1gb,+abm -drive file=/usr/share/ovmf/x64/ovmf_code_x64.bin,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/dc_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 647fd6b2-9a88-4219-af46-052f68a539a5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-dc/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 -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/mnt/shared/server/root/var/lib/libvirt/images/hdd/dc.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:58:ce:4e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + +I tried other QXL drivers: 22.33.46.473. +These work (but have a older date: 2015-07-28. + +17.54.59.923 have the date 2016-04-21. +I got them from this package: + +http://depot.flexvdi.com/guest-tools/flexvdi-guest-tools-2.2.11.iso + +Those provide something, which lets my window resize freely. + +I'm running into this issue as well: +Arch Linux +Qemu 2.8.0 +spice guest tools: 0.132 +QXL driver version (as reported by Windows Device Manager): 10.0.0.15000 + +Everything else works great. It would save me a lot of rebooting if this could get fixed. +If there is anything I can do or try, I'll be glad to help. + +Relevant log of VM boot and crash on selecting suspend action in virt-manager: + +2017-04-06 16:59:24.681+0000: starting up libvirt version: 3.1.0, qemu version: 2.8.0, hostname: arch-vaio.localdomain +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name guest=Windows,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-9-Windows/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu core2duo,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid f14684d3-5f81-4743-8512-e516d85ca2c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-9-Windows/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/mnt/media/Qemu/windows10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev user,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:44:08:31,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input2,bus=usb.0,port=3 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on +char device redirected to /dev/pts/6 (label charserial0) +main_channel_link: add main channel client +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +main_channel_handle_parsed: agent start +ehci warning: guest updated active QH +qemu-system-x86_64: /build/qemu/src/qemu-2.8.0/hw/display/qxl.c:2173: qxl_pre_save: Assertion `d->last_release_offset < d->vga.vram_size' failed. +2017-04-06 17:00:32.819+0000: shutting down, reason=crashed + +I can see a bunch of similar looking failures in Fedora's automatic backtrace stats system + +I put my money on that one: + +https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa + +commit f6e099db39e7d0787f294d5fd0dce328b5210faa +Author: Sameeh Jubran <email address hidden> +Date: Sun Sep 11 16:05:24 2016 +0300 + + Use the second bar (VRAM) for qxl command buffer. + + Based on a patch by Sandy Stutsman <email address hidden> + + Signed-off-by: Sameeh Jubran <email address hidden> + Acked-by: Frediano Ziglio <email address hidden> + + + +Crash reproduced immediately after setting up a win10 VM with qxl driver 10.0.0.15000. + +Gerd, are you looking into fixing it? Is it acceptable to crash qemu if the driver is faulty? + +damn launchpad, wrong bug and I can't change it back. Please someone move it back to New/Confirmed + +Well. qxl commands are expected to live in bar 0 (same bar where the rings are too). vram bar was added as surface storage. + +Now the windows drivers started to us vram for qxl commands. Problem is we simply can't live-migrate such a guest. At least not without changing the vmstate format. Which isn't something I would attempt just a few days before release. + +We can't throw an error in qxl_pre_save either (and fail migration instead of aborting). + +I don't see an easy way out for 2.9. + +Long term options are (a) revert the driver change, and probably add some checks to qxl to make sure guests don't use vram for commands, or (b) extend qxl vmstate so we can handle that case. + +An untested hack that might fail cleaner might be: + + error_report("Broken driver ..... migration failed"); + qemu_file_set_error(migrate_get_current()->to_dst_file, -EINVAL); + +(untested, probably needs checking it works with savevm). + +I must go around and add a return value to pre_save(). + +We probably also need to make sure some migration testing gets added to the driver dev + +Not sure we want a failure mode for pre_save(). + +If we go for option (a) (from comment 9), I'd add a check when reading the commands from the ring, not at migration time, so we don't run enter a state where pre_save() can fail in the first place. Because that will break the windows drivers we might add a warning only for 2.9, then for 2.10 raise an error irq. Something like this: + +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -639,6 +639,24 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size)) { ++#if 1 ++ /* temporary, for 2.9 */ ++ static int once; ++ if (!once) { ++ fprintf(stderr, "qxl: guest bug: command not in ram bar, " ++ "guest not migratable\n"); ++ once = true; ++ } ++#else ++ qxl_set_guest_bug(qxl, "command not in ram bar"); ++ return false; ++#endif ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: + + +Your approach works ok Gerd with a migration blocker. Are you going to send a patch? + +I am afraid we would have to make this code permanent though, since there has been several releases of this driver already, and it's much nicer to block migration than to crash a VM. + +I have reached out to wddm driver about the bug. + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 22 ++++++++++++++++++++++ + 2 files changed, 23 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..74ebeb9 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +-- +2.9.3 + + + +Hi + +On Mon, Apr 10, 2017 at 8:58 AM Gerd Hoffmann <email address hidden> wrote: + +> Cc: <email address hidden> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> --- +> hw/display/qxl.h | 1 + +> hw/display/qxl.c | 22 ++++++++++++++++++++++ +> 2 files changed, 23 insertions(+) +> +> diff --git a/hw/display/qxl.h b/hw/display/qxl.h +> index d2d49dd..77e5a36 100644 +> --- a/hw/display/qxl.h +> +++ b/hw/display/qxl.h +> @@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { +> uint32_t cmdlog; +> +> uint32_t guest_bug; +> + Error *migration_blocker; +> +> enum qxl_mode mode; +> uint32_t cmdflags; +> diff --git a/hw/display/qxl.c b/hw/display/qxl.c +> index c31b293..74ebeb9 100644 +> --- a/hw/display/qxl.c +> +++ b/hw/display/qxl.c +> @@ -26,6 +26,7 @@ +> #include "qemu/queue.h" +> #include "qemu/atomic.h" +> #include "sysemu/sysemu.h" +> +#include "migration/migration.h" +> #include "trace.h" +> +> #include "qxl.h" +> @@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, +> struct QXLCommandExt *ext) +> qxl->guest_primary.commands++; +> qxl_track_command(qxl, ext); +> qxl_log_command(qxl, "cmd", ext); +> + { +> + /* +> + * Windows 8 drivers place qxl commands in the vram +> ++ * (instead of the ram) bar. We can't live migrate such a +> + * guest, so add a migration blocker in case we detect +> + * this, to avoid triggering the assert in pre_save(). +> + * +> + * +> https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa +> + */ +> + void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); +> + if (msg != NULL && ( +> + msg < (void *)qxl->vga.vram_ptr || +> + msg > ((void *)qxl->vga.vram_ptr + +> qxl->vga.vram_size))) { +> + if (!qxl->migration_blocker) { +> + Error *local_err = NULL; +> + error_setg(&qxl->migration_blocker, +> + "qxl: guest bug: command not in ram bar"); +> + migrate_add_blocker(qxl->migration_blocker, +> &local_err); +> + } +> + +Should the blocker be removed on reset? + +Looks and works ok otherwise + + +> + } +> + } +> trace_qxl_ring_command_get(qxl->id, +> qxl_mode_to_string(qxl->mode)); +> return true; +> default: +> -- +> 2.9.3 +> +> -- +Marc-André Lureau + + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 28 ++++++++++++++++++++++++++++ + 2 files changed, 29 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..c1f830c 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +@@ -1236,6 +1258,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int loadvm) + qemu_spice_create_host_memslot(&d->ssd); + qxl_soft_reset(d); + ++ if (d->migration_blocker) { ++ migrate_del_blocker(d->migration_blocker); ++ error_free(d->migration_blocker); ++ d->migration_blocker = NULL; ++ } ++ + if (startstop) { + qemu_spice_display_start(); + } +-- +2.9.3 + + + +Hi + +On Mon, Apr 10, 2017 at 12:27 PM Gerd Hoffmann <email address hidden> wrote: + +> Cc: <email address hidden> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> +--- +> hw/display/qxl.h | 1 + +> hw/display/qxl.c | 28 ++++++++++++++++++++++++++++ +> 2 files changed, 29 insertions(+) +> +> diff --git a/hw/display/qxl.h b/hw/display/qxl.h +> index d2d49dd..77e5a36 100644 +> --- a/hw/display/qxl.h +> +++ b/hw/display/qxl.h +> @@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { +> uint32_t cmdlog; +> +> uint32_t guest_bug; +> + Error *migration_blocker; +> +> enum qxl_mode mode; +> uint32_t cmdflags; +> diff --git a/hw/display/qxl.c b/hw/display/qxl.c +> index c31b293..c1f830c 100644 +> --- a/hw/display/qxl.c +> +++ b/hw/display/qxl.c +> @@ -26,6 +26,7 @@ +> #include "qemu/queue.h" +> #include "qemu/atomic.h" +> #include "sysemu/sysemu.h" +> +#include "migration/migration.h" +> #include "trace.h" +> +> #include "qxl.h" +> @@ -639,6 +640,27 @@ static int interface_get_command(QXLInstance *sin, +> struct QXLCommandExt *ext) +> qxl->guest_primary.commands++; +> qxl_track_command(qxl, ext); +> qxl_log_command(qxl, "cmd", ext); +> + { +> + /* +> + * Windows 8 drivers place qxl commands in the vram +> + * (instead of the ram) bar. We can't live migrate such a +> + * guest, so add a migration blocker in case we detect +> + * this, to avoid triggering the assert in pre_save(). +> + * +> + * +> https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa +> + */ +> + void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); +> + if (msg != NULL && ( +> + msg < (void *)qxl->vga.vram_ptr || +> + msg > ((void *)qxl->vga.vram_ptr + +> qxl->vga.vram_size))) { +> + if (!qxl->migration_blocker) { +> + Error *local_err = NULL; +> + error_setg(&qxl->migration_blocker, +> + "qxl: guest bug: command not in ram bar"); +> + migrate_add_blocker(qxl->migration_blocker, +> &local_err); +> + +What do you do with the local_err? error_report_err() perhaps ? + + +> + } +> + } +> + } +> trace_qxl_ring_command_get(qxl->id, +> qxl_mode_to_string(qxl->mode)); +> return true; +> default: +> @@ -1236,6 +1258,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int +> loadvm) +> qemu_spice_create_host_memslot(&d->ssd); +> qxl_soft_reset(d); +> +> + if (d->migration_blocker) { +> + migrate_del_blocker(d->migration_blocker); +> + error_free(d->migration_blocker); +> + d->migration_blocker = NULL; +> + } +> + +> if (startstop) { +> qemu_spice_display_start(); +> } +> -- +> 2.9.3 +> +> -- +Marc-André Lureau + + + Hi, + +> > + if (!qxl->migration_blocker) { +> > + Error *local_err = NULL; +> > + error_setg(&qxl->migration_blocker, +> > + "qxl: guest bug: command not in ram bar"); +> > + migrate_add_blocker(qxl->migration_blocker, +> > &local_err); +> > +> +> What do you do with the local_err? error_report_err() perhaps ? + +We can't error out at that point, unlike most migration blockers this +isn't added at device initialization time. + +So, yes, we could error_report it, but the message would end up in the +logfile unnoticed, so I'm not sure how useful that is ... + +cheers, + Gerd + + + +Hi + +On Mon, Apr 10, 2017 at 12:51 PM Gerd Hoffmann <email address hidden> wrote: + +> Hi, +> +> > > + if (!qxl->migration_blocker) { +> > > + Error *local_err = NULL; +> > > + error_setg(&qxl->migration_blocker, +> > > + "qxl: guest bug: command not in ram +> bar"); +> > > + migrate_add_blocker(qxl->migration_blocker, +> > > &local_err); +> > > +> > +> > What do you do with the local_err? error_report_err() perhaps ? +> +> We can't error out at that point, unlike most migration blockers this +> isn't added at device initialization time. +> +> So, yes, we could error_report it, but the message would end up in the +> logfile unnoticed, so I'm not sure how useful that is ... +> + +Well, it may eventually be read if something breaks. Otherwise, you may +just pass a NULL pointer, no? + +thanks +-- +Marc-André Lureau + + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 31 +++++++++++++++++++++++++++++++ + 2 files changed, 32 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..9feae78 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,30 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ if (local_err) { ++ error_report_err(local_err); ++ } ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +@@ -1236,6 +1261,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int loadvm) + qemu_spice_create_host_memslot(&d->ssd); + qxl_soft_reset(d); + ++ if (d->migration_blocker) { ++ migrate_del_blocker(d->migration_blocker); ++ error_free(d->migration_blocker); ++ d->migration_blocker = NULL; ++ } ++ + if (startstop) { + qemu_spice_display_start(); + } +-- +2.9.3 + + + +Is this problem limited to commands or also to data attached to the commands? +To me looks like a limitation Qemu should remove on the long run. + +Hi + +On Mon, Apr 10, 2017 at 1:31 PM Gerd Hoffmann <email address hidden> wrote: + +> Cc: <email address hidden> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> + + +Reviewed-by: Marc-André Lureau <email address hidden> + + + +> --- +> hw/display/qxl.h | 1 + +> hw/display/qxl.c | 31 +++++++++++++++++++++++++++++++ +> 2 files changed, 32 insertions(+) +> +> diff --git a/hw/display/qxl.h b/hw/display/qxl.h +> index d2d49dd..77e5a36 100644 +> --- a/hw/display/qxl.h +> +++ b/hw/display/qxl.h +> @@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { +> uint32_t cmdlog; +> +> uint32_t guest_bug; +> + Error *migration_blocker; +> +> enum qxl_mode mode; +> uint32_t cmdflags; +> diff --git a/hw/display/qxl.c b/hw/display/qxl.c +> index c31b293..9feae78 100644 +> --- a/hw/display/qxl.c +> +++ b/hw/display/qxl.c +> @@ -26,6 +26,7 @@ +> #include "qemu/queue.h" +> #include "qemu/atomic.h" +> #include "sysemu/sysemu.h" +> +#include "migration/migration.h" +> #include "trace.h" +> +> #include "qxl.h" +> @@ -639,6 +640,30 @@ static int interface_get_command(QXLInstance *sin, +> struct QXLCommandExt *ext) +> qxl->guest_primary.commands++; +> qxl_track_command(qxl, ext); +> qxl_log_command(qxl, "cmd", ext); +> + { +> + /* +> + * Windows 8 drivers place qxl commands in the vram +> + * (instead of the ram) bar. We can't live migrate such a +> + * guest, so add a migration blocker in case we detect +> + * this, to avoid triggering the assert in pre_save(). +> + * +> + * +> https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa +> + */ +> + void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); +> + if (msg != NULL && ( +> + msg < (void *)qxl->vga.vram_ptr || +> + msg > ((void *)qxl->vga.vram_ptr + +> qxl->vga.vram_size))) { +> + if (!qxl->migration_blocker) { +> + Error *local_err = NULL; +> + error_setg(&qxl->migration_blocker, +> + "qxl: guest bug: command not in ram bar"); +> + migrate_add_blocker(qxl->migration_blocker, +> &local_err); +> + if (local_err) { +> + error_report_err(local_err); +> + } +> + } +> + } +> + } +> trace_qxl_ring_command_get(qxl->id, +> qxl_mode_to_string(qxl->mode)); +> return true; +> default: +> @@ -1236,6 +1261,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int +> loadvm) +> qemu_spice_create_host_memslot(&d->ssd); +> qxl_soft_reset(d); +> +> + if (d->migration_blocker) { +> + migrate_del_blocker(d->migration_blocker); +> + error_free(d->migration_blocker); +> + d->migration_blocker = NULL; +> + } +> + +> if (startstop) { +> qemu_spice_display_start(); +> } +> -- +> 2.9.3 +> +> -- +Marc-André Lureau + + +On Mo, 2017-04-10 at 11:56 +0000, Frediano Ziglio wrote: +> Is this problem limited to commands or also to data attached to the commands? + +Everything which contains QXLReleaseInfo and is released via release +ring. + +> To me looks like a limitation Qemu should remove on the long run. + +That is an option, but it is tricky backward-compatibility wise. +What was the reason to move the commands to bar1? + +cheers, + Gerd + + + +Cc: <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +Message-id: <email address hidden> +--- + hw/display/qxl.h | 1 + + hw/display/qxl.c | 31 +++++++++++++++++++++++++++++++ + 2 files changed, 32 insertions(+) + +diff --git a/hw/display/qxl.h b/hw/display/qxl.h +index d2d49dd..77e5a36 100644 +--- a/hw/display/qxl.h ++++ b/hw/display/qxl.h +@@ -40,6 +40,7 @@ typedef struct PCIQXLDevice { + uint32_t cmdlog; + + uint32_t guest_bug; ++ Error *migration_blocker; + + enum qxl_mode mode; + uint32_t cmdflags; +diff --git a/hw/display/qxl.c b/hw/display/qxl.c +index c31b293..9feae78 100644 +--- a/hw/display/qxl.c ++++ b/hw/display/qxl.c +@@ -26,6 +26,7 @@ + #include "qemu/queue.h" + #include "qemu/atomic.h" + #include "sysemu/sysemu.h" ++#include "migration/migration.h" + #include "trace.h" + + #include "qxl.h" +@@ -639,6 +640,30 @@ static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext) + qxl->guest_primary.commands++; + qxl_track_command(qxl, ext); + qxl_log_command(qxl, "cmd", ext); ++ { ++ /* ++ * Windows 8 drivers place qxl commands in the vram ++ * (instead of the ram) bar. We can't live migrate such a ++ * guest, so add a migration blocker in case we detect ++ * this, to avoid triggering the assert in pre_save(). ++ * ++ * https://cgit.freedesktop.org/spice/win32/qxl-wddm-dod/commit/?id=f6e099db39e7d0787f294d5fd0dce328b5210faa ++ */ ++ void *msg = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id); ++ if (msg != NULL && ( ++ msg < (void *)qxl->vga.vram_ptr || ++ msg > ((void *)qxl->vga.vram_ptr + qxl->vga.vram_size))) { ++ if (!qxl->migration_blocker) { ++ Error *local_err = NULL; ++ error_setg(&qxl->migration_blocker, ++ "qxl: guest bug: command not in ram bar"); ++ migrate_add_blocker(qxl->migration_blocker, &local_err); ++ if (local_err) { ++ error_report_err(local_err); ++ } ++ } ++ } ++ } + trace_qxl_ring_command_get(qxl->id, qxl_mode_to_string(qxl->mode)); + return true; + default: +@@ -1236,6 +1261,12 @@ static void qxl_hard_reset(PCIQXLDevice *d, int loadvm) + qemu_spice_create_host_memslot(&d->ssd); + qxl_soft_reset(d); + ++ if (d->migration_blocker) { ++ migrate_del_blocker(d->migration_blocker); ++ error_free(d->migration_blocker); ++ d->migration_blocker = NULL; ++ } ++ + if (startstop) { + qemu_spice_display_start(); + } +-- +2.9.3 + + + +Did I miss something or this is a bug in the windows qxl driver and should be fixed there? + +Will be fixed in the windows driver, yes. + +But throwing core dumps isn't exactly nice, even in case the guest is buggy, thats why the qemu workaround, so we simply refuse to live-migrate instead of crashing. + +Next version of the driver will solve the problem (already fixed in master). + +Similar issue, seems not caused by save/restore/migration but is still detecting offset problems with resource deallocation. +See https://lists.freedesktop.org/archives/spice-devel/2017-April/037248.html. + +Still working on some updates for the driver. + +wddm dod 0.17 version released which fixes the issue guest side. + +Patch had been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=86dbcdd9c7590d06db89ca +... thus closing this ticket now. + diff --git a/results/classifier/105/KVM/1637511 b/results/classifier/105/KVM/1637511 new file mode 100644 index 00000000..3bbb78bf --- /dev/null +++ b/results/classifier/105/KVM/1637511 @@ -0,0 +1,43 @@ +KVM: 0.903 +graphic: 0.741 +other: 0.712 +semantic: 0.630 +device: 0.587 +mistranslation: 0.576 +instruction: 0.529 +network: 0.520 +socket: 0.491 +boot: 0.348 +assembly: 0.322 +vnc: 0.192 + +Armitage crashes KVM guest with Kali2016.2 for QXL video + +I recently got a strange bug which seems to be related to qemu-kvm and QXL. I came here via the hints of the KVM web-site for KVM/qemu bug tracking. But, I am not sure whether this is the right bug-tracker at all. Please advise me if I placed the report wrongly. + +I installed Kali2016.2 as a KVM guest on a Opensuse Leap 42.1 host (fully updated). The KVM guest machine was configured to use a spice display and QXL video. Everything OK with the installation with the exception of one major application with a Java interface - Armitage. + +Armitage is correctly configured and starts (with some minor Java errors) and opens its interface (msf console, target window etc.) Trying to open the 2 specific menu points "Hosts" or "Attack" in the menu bar leads to something very strange: The screen flickers, then the whole login session is stopped and a standard login window opens. This happens independently of the setting for the type of Armitage target window (graphical or table like) + +Why do I report this bug here? +Because it happens with the QXL graphical video interface ONLY - not with video=vga or vmvga ! Neither does the bug occur when Armitage is started in a ssh (-X) session from the host. + +So, it is closely related to qemu-kvm AND QXL and the Java interaction with both. + +I really wonder what in the world can make 2 specific menu points of a Java application crash a KVM guest and restart a login shell in Kali only when QXL is used? + +qemu-kvm version : 2.3.1 +Kernel version of OS LEAP 42.1: Linux 4.1.31-30-default + +I have described the bug also to the Kali people - see https://bugs.kali.org/view.php?id=3698 + +Please inform me what further data are required - if this is relevant in this bug-tracker at all. + +If it's related to QXL, you should likely rather report this bug to the Spice people instead of QEMU. See https://www.spice-space.org/support.html for more information. + +Is this still an issue with the latest version? Did you ever report it to the Spice project? + +Can be closed - did not happen in later versions + +Ok, thanks for your answer, so I'm closing this ticket now. + diff --git a/results/classifier/105/KVM/1642011 b/results/classifier/105/KVM/1642011 new file mode 100644 index 00000000..63669df5 --- /dev/null +++ b/results/classifier/105/KVM/1642011 @@ -0,0 +1,36 @@ +KVM: 0.955 +device: 0.930 +network: 0.900 +graphic: 0.883 +socket: 0.856 +instruction: 0.854 +vnc: 0.782 +semantic: 0.772 +mistranslation: 0.739 +other: 0.637 +boot: 0.588 +assembly: 0.415 + +Mouse wheel events not forwarded to guest using GTK display + +Using QEMU 2.7.0 with KVM enabled, when I launch the guest without options (using the default of gtk), the mouse wheel events are not propagated to the guest. + +When I start qemu using -display sdk, mouse wheel events are properly forwarded. + +I can determine that the guest is not receiving mouse wheel events by doing cat /dev/input/by-id/usb-QEMU_QEMU_USB_Mouse_42-event-mouse. When I scroll the wheel, no output is printed to the screen. + +The guest is ChromiumOS. + +The command line is: + +qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -vga cirrus -usbdevice mouse -pidfile /tmp/kvm.pid -chardev pipe,id=control_pipe,path=/tmp/kvm.pipe -serial file:/tmp/kvm.serial -mon chardev=control_pipe -net nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:9222-:22 -drive file=chromiumos/src/build/images/amd64-generic/latest/chromiumos_qemu_image.bin,index=0,media=disk,cache=unsafe + +(Most of that invocation sets up Linux fifos for various and nefarious purposes and can be profitably ignored). + +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 all 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". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1652 b/results/classifier/105/KVM/1652 new file mode 100644 index 00000000..6ed61884 --- /dev/null +++ b/results/classifier/105/KVM/1652 @@ -0,0 +1,45 @@ +mistranslation: 0.986 +KVM: 0.981 +vnc: 0.981 +semantic: 0.976 +network: 0.975 +device: 0.975 +other: 0.975 +assembly: 0.975 +socket: 0.974 +graphic: 0.974 +instruction: 0.973 +boot: 0.972 + +make check failed about qemu@master on debian10_aarch64 +Description of problem: +make check failed about qemu@master on debian10_aarch64 +Steps to reproduce: +1../configure +2.make -j16 +3.make -j16 check +Additional information: +error: +>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=105 QTEST_QEMU_BINARY=./qemu-system-aarch64 /home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/build/tests/qtest/migration-test --tap -k +――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +stderr: +Broken pipe +../tests/qtest/libqtest.c:184: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) + + +TAP parsing error: Too few tests run (expected 18, got 0) +(test program exited with status code -6) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― + +190/627 qemu:qtest+qtest-aarch64 / qtest-aarch64/arm-cpu-features ERROR 0.34s killed by signal 6 SIGABRT +>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=115 QTEST_QEMU_BINARY=./qemu-system-aarch64 /home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/build/tests/qtest/arm-cpu-features --tap -k +――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +stderr: +qemu-system-aarch64: Failed to retrieve host CPU features +Broken pipe +../tests/qtest/libqtest.c:184: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) + + +TAP parsing error: Too few tests run (expected 5, got 1) +(test program exited with status code -6) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― diff --git a/results/classifier/105/KVM/1663287 b/results/classifier/105/KVM/1663287 new file mode 100644 index 00000000..af9c14b9 --- /dev/null +++ b/results/classifier/105/KVM/1663287 @@ -0,0 +1,126 @@ +KVM: 0.809 +other: 0.796 +vnc: 0.790 +device: 0.782 +mistranslation: 0.774 +boot: 0.768 +instruction: 0.732 +semantic: 0.709 +graphic: 0.686 +assembly: 0.669 +network: 0.647 +socket: 0.624 + +Illegal delay slot code causes abort on mips64 + +During some randomised testing of an experimental MIPS implementation I found an instruction sequence that also causes aborts on mainline qemu's MIPS support. The problem is triggered by an MSA branch instruction appearing in a delay slot when emulating a processor without MSA support. + +For example, with the current repository HEAD (f073cd3a2bf1054135271b837c58a7da650dd84b) configured for mips64-softmmu, if I run the attached binary using + + mips64-softmmu/qemu-system-mips64 -bios ../abort2.bin -machine mipssim -nographic + +it will report + + unknown branch 0x13000 + Aborted (core dumped) + +The binary contains the following two instructions: + + 00200008 jr at + 47081e61 bz.b w8,0xffffffffbfc0798c + +The jr sets up a jump, and hflags is set accordingly in gen_compute_branch (in target/mips/translate.c). When processing the bz.b, check_insn generates an exception because the instruction isn't support, but gen_msa_branch skips the usual delay slot check for the same reason, and sets more bits in hflags, leading to an abort in gen_branch because the hflags are now invalid. + +I suspect the best fix is to remove the instruction set condition from the delay slot check in gen_msa_branch. + + + +I've just found the same problem with gen_compute_branch1, + +00200008 jr at +4540563a bc1any4f $fcc0,0xffffffffbfc158ec + +The cause is the same - if the instruction set is wrong then the delay slot check is skipped. + +Thanks for reporting this issue. +In fact, branches in a delay slot is "undefined" in the pre-Release 6 architecture. +MIPS architectre release 6 defines to signal Reserved Instruction exceptions for such cases. +However as it was undefined, it is better to signal RI and carry on rather than stopping simulation. +Hence I've made a patch for the msa case. +I will have a look into the other case. (sorry I've missed in the first place.) + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=075a1fe788d36b271ec2 + +Thanks for that fix. I've just noticed that the second part, in gen_compute_branch1, wasn't included, though. Could you take a look at it? + +I found the exact same bug. Tested on several hosts and qemu releases. The newest one I tested was on FreeBSD 12.1 host and qemu-4.1.1_1 built from ports. + +Instructions: + 4000d0: 0320f809 jalr t9 + 4000d4: 45454545 0x45454545 # bc1any4t $fcc1,0x800101f8 + +I was running qemu-mips as: + +qemu-system-mipsel -s -m 1024 -M malta \ + -kernel vmlinux-3.16.0-6-4kc-malta -initrd initrd.img-3.16.0-6-4kc-malta \ + -device virtio-blk-pci,drive=hd0 -drive if=none,id=hd0,format=qcow2,file=debian_wheezy_mipsel_standard.qcow2 \ + -append "root=/dev/vda1" \ + -device virtio-net-pci,netdev=net0 \ + -netdev user,id=net0,hostfwd=tcp::1666-:22,ipv6=off \ + -curses + +abort() was in target/mips/translate.c:12945, in gen_branch(). + +Doesn't really matter if the instruction is supported on given CPU, user can crash the qemu within guest. + +Hi Brian, + +You try to execute a CP1 instruction in a delay slot, +which triggers a Reserved Instruction exception. +Per the ISA the processor operation is UNPREDICTABLE in such case. + +What is the behavior on real hardware? +An assertion() seems appropriate. + +Your compiler might be buggy, or you are not compiling for the correct CPU +(or you are not using the correct QEMU cpu). + +I don't know how Brian go to his state. + +I should've mentioned though I was using custom binary (shellcode) that triggered this behavior. This code was not generated by compiler. + +However, I wanted to point out that user can crash the qemu host by running custom code from userspace. + +Unfortunately I can't test this behavior on real HW right now. + +Yeah, QEMU crashing is definitely a bug that we should fix. (NB that it's not a 'security' bug, though -- we make no guarantee that malicious code run under QEMU with TCG emulation is unable to escape from it: there's too much unaudited and old code for us to be able to safely make that guarantee.) + + +When I reread the thread I see Brian was doing some testing/fuzzing, that's why he found that out. + +I managed to get my old router running. It's BCM5354 (BCM3302 v2.9) running on Linux 2.4.35. +I used the following code (gnu as compiled but replaced the nop after branch with the branch instruction above): + + 4000d0: 10000003 b 4000e0 <__start+0x10> + 4000d4: 45454545 0x45454545 + ... + 4000e0: 2404002a li a0,42 + 4000e4: 24020fa1 li v0,4001 + 4000e8: 0000000c syscall + 4000ec: 00000000 nop + +Program was terminated with the trap Illegal instruction. + + +If my memory is correct, this problem doesn't need qemu to execute the code, it only needs it to translate the code. In the original test case the invalid instructions were actually dead code but still managed to crash qemu. + +I suggest following Yongbok Kim's approach and signalling Reserved Instruction in the same way R6 does. I think that's architecturally allowed, although I admit that it's ages since I looked at this. + + +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/63 + + diff --git a/results/classifier/105/KVM/1671876 b/results/classifier/105/KVM/1671876 new file mode 100644 index 00000000..52a5a3d5 --- /dev/null +++ b/results/classifier/105/KVM/1671876 @@ -0,0 +1,195 @@ +KVM: 0.566 +vnc: 0.523 +mistranslation: 0.502 +other: 0.474 +device: 0.468 +instruction: 0.450 +graphic: 0.446 +network: 0.418 +socket: 0.397 +assembly: 0.387 +semantic: 0.379 +boot: 0.341 + +qemu 2.7.0 segfaults in qemu_co_queue_run_restart() + +I've been experiencing frequent segfaults lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash usually happens in qemu_co_queue_run_restart(). I haven't seen this so far with any other guests or distros. + +Here is one back trace I obtained from one of the crashing VMs. + +------------------------------------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x000055c1656f3fa0 in qemu_co_enter_next (queue=queue@entry=0x55c1669e75e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#11 0x000055c165692060 in timer_cb (blk=0x55c1669e7590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#12 0x000055c16564f615 in timerlist_run_timers (timer_list=0x55c166a53e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#13 0x000055c16564f679 in timerlistgroup_run_timers (tlg=tlg@entry=0x55c167c81cf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#14 0x000055c16564ff47 in aio_dispatch (ctx=ctx@entry=0x55c167c81bb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#15 0x000055c1656500e8 in aio_poll (ctx=0x55c167c81bb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#16 0x000055c1654b1c79 in iothread_run (opaque=0x55c167c81960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#17 0x00007fbc4b64f0a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#18 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +------------------------------------------------------------------------------------------------- + +The code that crashes is this +------------------------------------------------------------------------------------------------- +void qemu_co_queue_run_restart(Coroutine *co) +{ + Coroutine *next; + + trace_qemu_co_queue_run_restart(co); + while ((next = QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { + QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); <--- Crash occurs here this time + qemu_coroutine_enter(next); + } +} +------------------------------------------------------------------------------------------------- + +Expanding the macro QSIMPLEQ_REMOVE_HEAD gives us +------------------------------------------------------------------------------------------------- +#define QSIMPLEQ_REMOVE_HEAD(head, field) do { \ + if (((head)->sqh_first = (head)->sqh_first->field.sqe_next) == NULL)\ + (head)->sqh_last = &(head)->sqh_first; \ +} while (/*CONSTCOND*/0) +------------------------------------------------------------------------------------------------- + +which corrsponds to +------------------------------------------------------------------------------------------------- +if (((&co->co_queue_wakeup)->sqh_first = (&co->co_queue_wakeup)->sqh_first->co_queue_next.sqe_next) == NULL)\ + (&co->co_queue_wakeup)->sqh_last = &(&co->co_queue_wakeup)->sqh_first; +------------------------------------------------------------------------------------------------- + +Debugging the list we see +------------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$6 = (struct Coroutine *) 0x1000 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x1030 +------------------------------------------------------------------------------------------------- + +So the data in co->co_queue_wakeup->sqh_first is corrupted and represents an invalid address. Any idea why is that? + +Another stack trace + +--------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7f668be15260) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x0000564cb19f59a9 in qemu_coroutine_enter (co=0x7f668be15260) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x0000564cb19f5fa0 in qemu_co_enter_next (queue=queue@entry=0x564cb35e55e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#3 0x0000564cb1994060 in timer_cb (blk=0x564cb35e5590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#4 0x0000564cb1951615 in timerlist_run_timers (timer_list=0x564cb3651e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#5 0x0000564cb1951679 in timerlistgroup_run_timers (tlg=tlg@entry=0x564cb487fcf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#6 0x0000564cb1951f47 in aio_dispatch (ctx=ctx@entry=0x564cb487fbb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#7 0x0000564cb19520e8 in aio_poll (ctx=0x564cb487fbb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#8 0x0000564cb17b3c79 in iothread_run (opaque=0x564cb487f960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#9 0x00007f684b0b30a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#10 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +----------------------------------------------------------------------------------------------- + + +Here is a bit of examination of the data +----------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$1 = (struct Coroutine *) 0xc54b578 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0xc54b5a8 +----------------------------------------------------------------------------------------------- + +Again seems to be pointing at an invalid address. It's worth noting here that it the number of restarted and re-run co-routines is much smaller. + +A third stack trace + +It generates the following stack trace +--------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7f75ed30dbc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed30dbc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75f1c0f200) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75f1c0f200) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed304870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed304870) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800fcd0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800fcd0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800fac0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800fac0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800f8b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#11 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800f8b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#12 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf05570) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#13 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf05570) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#14 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8009b70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#15 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8009b70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#16 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800b5d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#17 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800b5d0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#18 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8008910) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#19 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8008910) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#20 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800f6a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#21 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800f6a0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#22 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf05100) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#23 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf05100) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#24 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75fbf04ee0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#25 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75fbf04ee0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#26 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed301c50) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#27 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed301c50) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#28 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed315270) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#29 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed315270) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#30 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75ed31cf10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#31 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75ed31cf10) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#32 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800a970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#33 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800a970) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#34 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8007df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#35 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8007df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#36 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8005960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#37 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8005960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#38 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e800e1b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#39 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e800e1b0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#40 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8000a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#41 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8000a00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#42 0x0000561927482e74 in qemu_co_queue_run_restart (co=0x7f75e8007900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#43 0x00005619274829a9 in qemu_coroutine_enter (co=0x7f75e8007900) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#44 0x0000561927482fa0 in qemu_co_enter_next (queue=queue@entry=0x5619288d15e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#45 0x0000561927421060 in timer_cb (blk=0x5619288d1590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#46 0x00005619273de615 in timerlist_run_timers (timer_list=0x56192893de80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#47 0x00005619273de679 in timerlistgroup_run_timers (tlg=tlg@entry=0x561929b6bcf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#48 0x00005619273def47 in aio_dispatch (ctx=ctx@entry=0x561929b6bbb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#49 0x00005619273df0e8 in aio_poll (ctx=0x561929b6bbb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#50 0x0000561927240c79 in iothread_run (opaque=0x561929b6b960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#51 0x00007f77b32160a4 in start_thread (arg=0x7f77997ff700) at pthread_create.c:403 +#52 0x00007f77b2f4b62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +--------------------------------------------------------------------- + +It's also crashing in list traversal. Looking at the contained data we see: + +--------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$1 = (struct Coroutine *) 0x1 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x31 +--------------------------------------------------------------------- + +So again. Segfault is caused by apparently invalid addresses. And this time it occurs after so many invocations of qemu_co_queue_run_restart() + +The VMs were running with the following arguments +--------------------------------------------------------------------- +-m 1024,slots=255,maxmem=256G -M pc-i440fx-2.7 -enable-kvm -nodefconfig -nodefaults -rtc base=utc -netdev tap,ifname=n020133f0895e,id=hostnet6,vhost=on,vhostforce=on,vnet_hdr=off,script=no,downscript=no -device virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:33:f0:89:5e,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:94 -vga qxl -cpu Haswell,+vmx -smp 6,sockets=32,cores=1,maxcpus=64,threads=2 -drive file=/dev/md10,if=none,id=drive-virtio-disk5,format=raw,snapshot=off,aio=native,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk5,num-queues=3,id=virtio-disk5,bootindex=1 -S +--------------------------------------------------------------------- + + +Could you please retry with the latest stable version (either 2.8.0 or 2.7.1) ... maybe the problem is already fixed there. + +Unfortunately it'd not be possible to use another version at the moment. Is it possible that someone takes a look at the stack traces? + +Fixed by commit 528f449f590829b53ea01ed91817a695b540421d + diff --git a/results/classifier/105/KVM/1673722 b/results/classifier/105/KVM/1673722 new file mode 100644 index 00000000..0cf0a777 --- /dev/null +++ b/results/classifier/105/KVM/1673722 @@ -0,0 +1,126 @@ +KVM: 0.682 +graphic: 0.672 +mistranslation: 0.669 +network: 0.666 +vnc: 0.624 +device: 0.604 +other: 0.604 +assembly: 0.601 +boot: 0.584 +instruction: 0.581 +socket: 0.560 +semantic: 0.550 + +Reading register at offset. It is not fully implemented warning make VM impossible to use + +Hi, + +Since this commit: +https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 + +We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +e1000: Reading register at offset: 0x00002410. It is not fully implemented. + +User got so much of this warning that they can't use the VM. + +Thanks for the help + +On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote: +> Hi, +> +> Since this commit: +> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 +> +> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +> e1000: Reading register at offset: 0x00002410. It is not fully implemented. +> +> User got so much of this warning that they can't use the VM. + +CCing the author and maintainers. + +DBGOUT() is compiled in by default. Warnings that can be triggered at a +high rate by the guest should be off by default or use a +printf_once()-style macro so they are only printed once and not again. + +Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing +guest-triggerable messages by default? + +Stefan + + +On 20 March 2017 at 14:20, Stefan Hajnoczi <email address hidden> wrote: +> On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote: +>> Hi, +>> +>> Since this commit: +>> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 +>> +>> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +>> e1000: Reading register at offset: 0x00002410. It is not fully implemented. +>> +>> User got so much of this warning that they can't use the VM. +> +> CCing the author and maintainers. +> +> DBGOUT() is compiled in by default. Warnings that can be triggered at a +> high rate by the guest should be off by default or use a +> printf_once()-style macro so they are only printed once and not again. +> +> Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing +> guest-triggerable messages by default? + +If we want to report "whoops, we don't implement this yet" messages then +the recommended way to do that is + qemu_log_mask(LOG_UNIMP, "...."); + +(these are not reported by default but only if the user asks for them.) + +thanks +-- PMM + + + + +On 2017年03月20日 22:58, Peter Maydell wrote: +> On 20 March 2017 at 14:20, Stefan Hajnoczi <email address hidden> wrote: +>> On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote: +>>> Hi, +>>> +>>> Since this commit: +>>> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347 +>>> +>>> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying: +>>> e1000: Reading register at offset: 0x00002410. It is not fully implemented. +>>> +>>> User got so much of this warning that they can't use the VM. +>> CCing the author and maintainers. +>> +>> DBGOUT() is compiled in by default. Warnings that can be triggered at a +>> high rate by the guest should be off by default or use a +>> printf_once()-style macro so they are only printed once and not again. +>> +>> Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing +>> guest-triggerable messages by default? +> If we want to report "whoops, we don't implement this yet" messages then +> the recommended way to do that is +> qemu_log_mask(LOG_UNIMP, "...."); +> +> (these are not reported by default but only if the user asks for them.) +> +> thanks +> -- PMM +> + +I don't see a reason that enabling E1000E_DEBUG by default. How about +just disable it by default? + +Thanks + + +I sent a patch to the mailing list: +http://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg01294.html + +I think this has been fixed by: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b4053c64833 + + diff --git a/results/classifier/105/KVM/1675458 b/results/classifier/105/KVM/1675458 new file mode 100644 index 00000000..62457f0c --- /dev/null +++ b/results/classifier/105/KVM/1675458 @@ -0,0 +1,94 @@ +KVM: 0.844 +network: 0.832 +instruction: 0.765 +device: 0.744 +semantic: 0.734 +other: 0.723 +graphic: 0.720 +assembly: 0.718 +mistranslation: 0.715 +boot: 0.701 +socket: 0.668 +vnc: 0.584 + +attach-interface - unexpected action + +Hello, + +Not sure where to report this, or if it is a bug. However, I feel like the behaviour is not what would/should be expected. + +---------------------------------------------------------------------------------------------------------- + +Environment: +KVM Version: root@hostname:~# virsh version + Compiled against library: libvirt 1.2.9 + Using library: libvirt 1.2.9 + Using API: QEMU 1.2.9 + Running hypervisor: QEMU 2.1.2 +uname -a: Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux +CPU: Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz +Host Debian Version: 8.7 (Jessie) +Guest Debian Version: 8.7 (Jessie) + +---------------------------------------------------------------------------------------------------------- + +Issue: +When adding an interface to a live VM, the position of interfaces within the VM may change post reboot. +It appears a new interface takes up the first available “pci slot”. If you have removed an interface in the past, this will be the one that is taken up. + +---------------------------------------------------------------------------------------------------------- + +Example: + +If the VM Has the following interfaces layout: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 11:11:11:11:11:11 +eth2 HWaddr 22:22:22:22:22:22 +eth3 HWaddr 33:33:33:33:33:33 + +Now I delete the interface with MAC address 11:11:11:11:11:11, you now have this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 22:22:22:22:22:22 +eth2 HWaddr 33:33:33:33:33:33 + +And then you add a new interface with MAC address 44:44:44:44:44:44, using virsh: + +virsh attach-interface --domain guest --type bridge --source br3 --mac 44:44:44:44:44:44 --model e1000 --target vmeth3 --live --persistent + +It will now look like this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 22:22:22:22:22:22 +eth2 HWaddr 33:33:33:33:33:33 +eth3 HWaddr 44:44:44:44:44:44 + +However, after a reboot, it will look like this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 44:44:44:44:44:44 +eth2 HWaddr 22:22:22:22:22:22 +eth3 HWaddr 33:33:33:33:33:33 + +This can be a problem, as /etc/network/interfaces file, etc., will be pointing to the wrong interfaces. I.E. originally eth1 was connected to br1 (for example), after reboot eth1 is now connected to br3. + +To resolve this issue, I need to edit the .xml file in the KVM machine, and edit the following lines: + + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> + +Changing these into the order I want them to be loaded in, i.e. eth0, eth1, eth2…. (I know 4 are taken already and not usable by ethernet interfaces.) + +---------------------------------------------------------------------------------------------------------- + + +Thanks in advance. + +Kind regards, + +Aaron Doyle + +Looking through old bug tickets ... Have you tried to discuss this issue with the libvirt people? They might need to have a look at your virsh commands first before one could decide whether this is a libvirt or a qemu problem... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1677247 b/results/classifier/105/KVM/1677247 new file mode 100644 index 00000000..7b601bb1 --- /dev/null +++ b/results/classifier/105/KVM/1677247 @@ -0,0 +1,34 @@ +KVM: 0.917 +other: 0.835 +graphic: 0.812 +device: 0.765 +instruction: 0.750 +mistranslation: 0.667 +vnc: 0.518 +semantic: 0.508 +network: 0.418 +boot: 0.378 +socket: 0.302 +assembly: 0.277 + +QEMU e500 kvm no video and kernel crashing in virtios modules + +Hi, +i been attached the log of my issue on Qoriq e5500 +when i start qemu-system-ppc64 -cpu e5500 -M ppce500 --enable-kvm -device virtio-gpu-pci --nodefaults -display gtk and so and so . i have crashes in virtio modules in the VM and continue traces on the host machine. +If is needed more for investigating ask freely . + +Note: i use my selfmade kernel this machine dont have a distro kenels and official kernels. + + +Ciao +Luigi + + + +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/105/KVM/1681688 b/results/classifier/105/KVM/1681688 new file mode 100644 index 00000000..0e3494f3 --- /dev/null +++ b/results/classifier/105/KVM/1681688 @@ -0,0 +1,224 @@ +KVM: 0.615 +vnc: 0.555 +other: 0.496 +graphic: 0.456 +device: 0.438 +semantic: 0.425 +mistranslation: 0.413 +instruction: 0.413 +assembly: 0.395 +socket: 0.360 +network: 0.355 +boot: 0.345 + +qemu live migration failed + +qemu live migration failed + +the dest qemu report this error. + +Receiving block device images +Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. + +this bug is caused by this patch: +http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a + +rollback this commit, the problem solved. + +blk->root->perm is 1 when blk_new_open. + +the blk->root->perm is update to 3 during virtio_blk_device_realize. + +but after this commit, the blk->root->perm is still 1. and cause bdrv_aligned_pwritev failed. + +Breakpoint 1, blk_set_perm (blk=0x14c32b0, perm=3, shared_perm=29, errp=0x7fffffffd380) at block/block-backend.c:579 +579 { +(gdb) bt +#0 blk_set_perm (blk=0x14c32b0, perm=3, shared_perm=29, errp=0x7fffffffd380) at block/block-backend.c:579 +#1 0x000000000063484b in blkconf_apply_backend_options (conf=0x2de7fd0, readonly=false, resizable=true, errp=0x7fffffffd380) at hw/block/block.c:77 +#2 0x00000000004a57bd in virtio_blk_device_realize (dev=0x2de7e30, errp=0x7fffffffd3e0) at /data/qemu/hw/block/virtio-blk.c:931 +#3 0x00000000004f688e in virtio_device_realize (dev=0x2de7e30, errp=0x7fffffffd468) at /data/qemu/hw/virtio/virtio.c:2485 +#4 0x000000000065806f in device_set_realized (obj=0x2de7e30, value=true, errp=0x7fffffffd6d8) at hw/core/qdev.c:939 +#5 0x000000000083aaf5 in property_set_bool (obj=0x2de7e30, v=0x2e67a90, name=0xaf4b53 "realized", opaque=0x2de9660, errp=0x7fffffffd6d8) at qom/object.c:1860 +#6 0x0000000000838c46 in object_property_set (obj=0x2de7e30, v=0x2e67a90, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/object.c:1094 +#7 0x000000000083c23f in object_property_set_qobject (obj=0x2de7e30, value=0x2e679e0, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/qom-qobject.c:27 +#8 0x0000000000838f9a in object_property_set_bool (obj=0x2de7e30, value=true, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/object.c:1163 +#9 0x00000000007bafac in virtio_blk_pci_realize (vpci_dev=0x2ddf920, errp=0x7fffffffd6d8) at hw/virtio/virtio-pci.c:1975 +#10 0x00000000007ba966 in virtio_pci_realize (pci_dev=0x2ddf920, errp=0x7fffffffd6d8) at hw/virtio/virtio-pci.c:1853 +#11 0x000000000071e439 in pci_qdev_realize (qdev=0x2ddf920, errp=0x7fffffffd7b8) at hw/pci/pci.c:2001 +#12 0x00000000007badaa in virtio_pci_dc_realize (qdev=0x2ddf920, errp=0x7fffffffd7b8) at hw/virtio/virtio-pci.c:1930 +#13 0x000000000065806f in device_set_realized (obj=0x2ddf920, value=true, errp=0x7fffffffd9a8) at hw/core/qdev.c:939 +#14 0x000000000083aaf5 in property_set_bool (obj=0x2ddf920, v=0x2decfd0, name=0x9b2c0e "realized", opaque=0x2ddf5d0, errp=0x7fffffffd9a8) at qom/object.c:1860 +#15 0x0000000000838c46 in object_property_set (obj=0x2ddf920, v=0x2decfd0, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/object.c:1094 +#16 0x000000000083c23f in object_property_set_qobject (obj=0x2ddf920, value=0x2dece90, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/qom-qobject.c:27 +#17 0x0000000000838f9a in object_property_set_bool (obj=0x2ddf920, value=true, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/object.c:1163 +#18 0x00000000005bfcea in qdev_device_add (opts=0x1451320, errp=0x7fffffffda30) at qdev-monitor.c:624 +#19 0x00000000005c9662 in device_init_func (opaque=0x0, opts=0x1451320, errp=0x0) at vl.c:2305 +#20 0x000000000095f491 in qemu_opts_foreach (list=0xe5bd80, func=0x5c9624 <device_init_func>, opaque=0x0, errp=0x0) at util/qemu-option.c:1114 +#21 0x00000000005ce9be in main (argc=46, argv=0x7fffffffdeb8, envp=0x7fffffffe030) at vl.c:4583 + + +Hi Kevin: + Can you provide some information about the original bug which you want fix? + + the original comment: + Usually guest devices don't like other writers to the same image, so + they use blk_set_perm() to prevent this from happening. + + i don't find where the dest qemu will use blk_set_perm during migration. + but after apply this patch, blkconf_apply_backend_options don't update the + blk->root->perm. + + Thanks. + +On Tue, Apr 11, 2017 at 4:21 PM, Lidong Chen <email address hidden> wrote: +> blk->root->perm is 1 when blk_new_open. +> +> the blk->root->perm is update to 3 during virtio_blk_device_realize. +> +> but after this commit, the blk->root->perm is still 1. and cause +> bdrv_aligned_pwritev failed. +> +> Breakpoint 1, blk_set_perm (blk=0x14c32b0, perm=3, shared_perm=29, errp=0x7fffffffd380) at block/block-backend.c:579 +> 579 { +> (gdb) bt +> #0 blk_set_perm (blk=0x14c32b0, perm=3, shared_perm=29, errp=0x7fffffffd380) at block/block-backend.c:579 +> #1 0x000000000063484b in blkconf_apply_backend_options (conf=0x2de7fd0, readonly=false, resizable=true, errp=0x7fffffffd380) at hw/block/block.c:77 +> #2 0x00000000004a57bd in virtio_blk_device_realize (dev=0x2de7e30, errp=0x7fffffffd3e0) at /data/qemu/hw/block/virtio-blk.c:931 +> #3 0x00000000004f688e in virtio_device_realize (dev=0x2de7e30, errp=0x7fffffffd468) at /data/qemu/hw/virtio/virtio.c:2485 +> #4 0x000000000065806f in device_set_realized (obj=0x2de7e30, value=true, errp=0x7fffffffd6d8) at hw/core/qdev.c:939 +> #5 0x000000000083aaf5 in property_set_bool (obj=0x2de7e30, v=0x2e67a90, name=0xaf4b53 "realized", opaque=0x2de9660, errp=0x7fffffffd6d8) at qom/object.c:1860 +> #6 0x0000000000838c46 in object_property_set (obj=0x2de7e30, v=0x2e67a90, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/object.c:1094 +> #7 0x000000000083c23f in object_property_set_qobject (obj=0x2de7e30, value=0x2e679e0, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/qom-qobject.c:27 +> #8 0x0000000000838f9a in object_property_set_bool (obj=0x2de7e30, value=true, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/object.c:1163 +> #9 0x00000000007bafac in virtio_blk_pci_realize (vpci_dev=0x2ddf920, errp=0x7fffffffd6d8) at hw/virtio/virtio-pci.c:1975 +> #10 0x00000000007ba966 in virtio_pci_realize (pci_dev=0x2ddf920, errp=0x7fffffffd6d8) at hw/virtio/virtio-pci.c:1853 +> #11 0x000000000071e439 in pci_qdev_realize (qdev=0x2ddf920, errp=0x7fffffffd7b8) at hw/pci/pci.c:2001 +> #12 0x00000000007badaa in virtio_pci_dc_realize (qdev=0x2ddf920, errp=0x7fffffffd7b8) at hw/virtio/virtio-pci.c:1930 +> #13 0x000000000065806f in device_set_realized (obj=0x2ddf920, value=true, errp=0x7fffffffd9a8) at hw/core/qdev.c:939 +> #14 0x000000000083aaf5 in property_set_bool (obj=0x2ddf920, v=0x2decfd0, name=0x9b2c0e "realized", opaque=0x2ddf5d0, errp=0x7fffffffd9a8) at qom/object.c:1860 +> #15 0x0000000000838c46 in object_property_set (obj=0x2ddf920, v=0x2decfd0, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/object.c:1094 +> #16 0x000000000083c23f in object_property_set_qobject (obj=0x2ddf920, value=0x2dece90, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/qom-qobject.c:27 +> #17 0x0000000000838f9a in object_property_set_bool (obj=0x2ddf920, value=true, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/object.c:1163 +> #18 0x00000000005bfcea in qdev_device_add (opts=0x1451320, errp=0x7fffffffda30) at qdev-monitor.c:624 +> #19 0x00000000005c9662 in device_init_func (opaque=0x0, opts=0x1451320, errp=0x0) at vl.c:2305 +> #20 0x000000000095f491 in qemu_opts_foreach (list=0xe5bd80, func=0x5c9624 <device_init_func>, opaque=0x0, errp=0x0) at util/qemu-option.c:1114 +> #21 0x00000000005ce9be in main (argc=46, argv=0x7fffffffdeb8, envp=0x7fffffffe030) at vl.c:4583 +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1681688 +> +> Title: +> qemu live migration failed +> +> Status in QEMU: +> New +> +> Bug description: +> qemu live migration failed +> +> the dest qemu report this error. +> +> Receiving block device images +> Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. +> +> this bug is caused by this patch: +> http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a +> +> rollback this commit, the problem solved. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1681688/+subscriptions +> + + +Am 11.04.2017 um 15:35 hat 858585 jemmy geschrieben: +> Hi Kevin: +> Can you provide some information about the original bug which you want fix? +> +> the original comment: +> Usually guest devices don't like other writers to the same image, so +> they use blk_set_perm() to prevent this from happening. +> +> i don't find where the dest qemu will use blk_set_perm during migration. +> but after apply this patch, blkconf_apply_backend_options don't update the +> blk->root->perm. + +Do I understand correctly that this is not simply live migration, but +block live migration (with 'migrate -b')? + +Can you please post a backtrace not of the successful case, but of the +failing assertion? + +Kevin + +> On Tue, Apr 11, 2017 at 4:21 PM, Lidong Chen <email address hidden> wrote: +> > blk->root->perm is 1 when blk_new_open. +> > +> > the blk->root->perm is update to 3 during virtio_blk_device_realize. +> > +> > but after this commit, the blk->root->perm is still 1. and cause +> > bdrv_aligned_pwritev failed. +> > +> > Breakpoint 1, blk_set_perm (blk=0x14c32b0, perm=3, shared_perm=29, errp=0x7fffffffd380) at block/block-backend.c:579 +> > 579 { +> > (gdb) bt +> > #0 blk_set_perm (blk=0x14c32b0, perm=3, shared_perm=29, errp=0x7fffffffd380) at block/block-backend.c:579 +> > #1 0x000000000063484b in blkconf_apply_backend_options (conf=0x2de7fd0, readonly=false, resizable=true, errp=0x7fffffffd380) at hw/block/block.c:77 +> > #2 0x00000000004a57bd in virtio_blk_device_realize (dev=0x2de7e30, errp=0x7fffffffd3e0) at /data/qemu/hw/block/virtio-blk.c:931 +> > #3 0x00000000004f688e in virtio_device_realize (dev=0x2de7e30, errp=0x7fffffffd468) at /data/qemu/hw/virtio/virtio.c:2485 +> > #4 0x000000000065806f in device_set_realized (obj=0x2de7e30, value=true, errp=0x7fffffffd6d8) at hw/core/qdev.c:939 +> > #5 0x000000000083aaf5 in property_set_bool (obj=0x2de7e30, v=0x2e67a90, name=0xaf4b53 "realized", opaque=0x2de9660, errp=0x7fffffffd6d8) at qom/object.c:1860 +> > #6 0x0000000000838c46 in object_property_set (obj=0x2de7e30, v=0x2e67a90, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/object.c:1094 +> > #7 0x000000000083c23f in object_property_set_qobject (obj=0x2de7e30, value=0x2e679e0, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/qom-qobject.c:27 +> > #8 0x0000000000838f9a in object_property_set_bool (obj=0x2de7e30, value=true, name=0xaf4b53 "realized", errp=0x7fffffffd6d8) at qom/object.c:1163 +> > #9 0x00000000007bafac in virtio_blk_pci_realize (vpci_dev=0x2ddf920, errp=0x7fffffffd6d8) at hw/virtio/virtio-pci.c:1975 +> > #10 0x00000000007ba966 in virtio_pci_realize (pci_dev=0x2ddf920, errp=0x7fffffffd6d8) at hw/virtio/virtio-pci.c:1853 +> > #11 0x000000000071e439 in pci_qdev_realize (qdev=0x2ddf920, errp=0x7fffffffd7b8) at hw/pci/pci.c:2001 +> > #12 0x00000000007badaa in virtio_pci_dc_realize (qdev=0x2ddf920, errp=0x7fffffffd7b8) at hw/virtio/virtio-pci.c:1930 +> > #13 0x000000000065806f in device_set_realized (obj=0x2ddf920, value=true, errp=0x7fffffffd9a8) at hw/core/qdev.c:939 +> > #14 0x000000000083aaf5 in property_set_bool (obj=0x2ddf920, v=0x2decfd0, name=0x9b2c0e "realized", opaque=0x2ddf5d0, errp=0x7fffffffd9a8) at qom/object.c:1860 +> > #15 0x0000000000838c46 in object_property_set (obj=0x2ddf920, v=0x2decfd0, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/object.c:1094 +> > #16 0x000000000083c23f in object_property_set_qobject (obj=0x2ddf920, value=0x2dece90, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/qom-qobject.c:27 +> > #17 0x0000000000838f9a in object_property_set_bool (obj=0x2ddf920, value=true, name=0x9b2c0e "realized", errp=0x7fffffffd9a8) at qom/object.c:1163 +> > #18 0x00000000005bfcea in qdev_device_add (opts=0x1451320, errp=0x7fffffffda30) at qdev-monitor.c:624 +> > #19 0x00000000005c9662 in device_init_func (opaque=0x0, opts=0x1451320, errp=0x0) at vl.c:2305 +> > #20 0x000000000095f491 in qemu_opts_foreach (list=0xe5bd80, func=0x5c9624 <device_init_func>, opaque=0x0, errp=0x0) at util/qemu-option.c:1114 +> > #21 0x00000000005ce9be in main (argc=46, argv=0x7fffffffdeb8, envp=0x7fffffffe030) at vl.c:4583 +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1681688 +> > +> > Title: +> > qemu live migration failed +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > qemu live migration failed +> > +> > the dest qemu report this error. +> > +> > Receiving block device images +> > Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. +> > +> > this bug is caused by this patch: +> > http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a +> > +> > rollback this commit, the problem solved. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1681688/+subscriptions +> > + + +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/105/KVM/1682128 b/results/classifier/105/KVM/1682128 new file mode 100644 index 00000000..3f953902 --- /dev/null +++ b/results/classifier/105/KVM/1682128 @@ -0,0 +1,19 @@ +KVM: 0.984 +mistranslation: 0.945 +graphic: 0.893 +device: 0.853 +other: 0.798 +semantic: 0.745 +socket: 0.527 +boot: 0.512 +instruction: 0.481 +network: 0.334 +vnc: 0.174 +assembly: 0.128 + +solaris can't power off + +I have created solaris 10 VM on KVM. Everything in VM is running OK, but finally I use shell command ‘poweroff’ or ‘init 5’, the solaris VM system could’t be poweroff but with promoting me the message: perss any key to reboot ….. + +but on Xen, solaris can be powerofff + diff --git a/results/classifier/105/KVM/1686350 b/results/classifier/105/KVM/1686350 new file mode 100644 index 00000000..7380fd3a --- /dev/null +++ b/results/classifier/105/KVM/1686350 @@ -0,0 +1,64 @@ +KVM: 0.927 +device: 0.531 +semantic: 0.500 +instruction: 0.488 +graphic: 0.354 +socket: 0.295 +network: 0.270 +other: 0.238 +mistranslation: 0.233 +boot: 0.187 +assembly: 0.177 +vnc: 0.124 + +[KVM] The qemu ‘-cpu’ option not have skylake server cpu model + +Environment: +------------------- +KVM commit/branch: bd17117b/next +Qemu commit/branch: cd1ea508/master +Host OS: RHEL7.3 ia32e +Host Kernel:4.11.0-rc3 +Bug detailed description: +---------------------------------- +In latest qemu commit the qemu still not have skylake server cpu model +Reproduce steps: +------------------------- +[root@skl-2s2 ~]# qemu-system-x86_64 -cpu help +Available CPUs: +x86 486 +x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX) +x86 Broadwell Intel Core Processor (Broadwell) +x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) +x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX) +x86 Haswell Intel Core Processor (Haswell) +x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge) +x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) +x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron) +x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) +x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) +x86 Opteron_G4 AMD Opteron 62xx class CPU +x86 Opteron_G5 AMD Opteron 63xx class CPU +x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) +x86 SandyBridge Intel Xeon E312xx (Sandy Bridge) +x86 Skylake-Client Intel Core Processor (Skylake) +x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) +x86 athlon QEMU Virtual CPU version 2.5+ +x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz +x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz +x86 kvm32 Common 32-bit KVM processor +x86 kvm64 Common KVM processor +x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz +x86 pentium +x86 pentium2 +x86 pentium3 +x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor +x86 qemu32 QEMU Virtual CPU version 2.5+ +x86 qemu64 QEMU Virtual CPU version 2.5+ +x86 base base CPU model type with no features enabled +x86 host KVM processor with all supported host features (only available in KVM mode) +x86 max Enables all features supported by the accelerator in the current host + +The Skylake-Server cpu type was added for either QEMU 3.0 or 3.1, so this bug is fix-released. + + diff --git a/results/classifier/105/KVM/1688 b/results/classifier/105/KVM/1688 new file mode 100644 index 00000000..3cf779d1 --- /dev/null +++ b/results/classifier/105/KVM/1688 @@ -0,0 +1,46 @@ +KVM: 0.978 +graphic: 0.899 +instruction: 0.855 +semantic: 0.835 +device: 0.835 +network: 0.740 +socket: 0.684 +vnc: 0.628 +mistranslation: 0.627 +boot: 0.459 +assembly: 0.330 +other: 0.320 + +target/riscv KVM_RISCV_SET_TIMER macro is not configured correctly +Description of problem: +When riscv kvm vm state changed, guest virtual time would stop/continue. But KVM_RISCV_SET_TIMER is wrong, qemu-kvm can only set 'time'. +Steps to reproduce: +1.start host kernel +2.start qemu-kvm +Additional information: +Below code has some probelm: +``` +=================================================================== +#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \ + do { \ + int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), ®); \ + +=================================================================== +``` +I think it should be like this: + +``` +diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c +index 30f21453d6..0c567f668c 100644 +--- a/target/riscv/kvm.c ++++ b/target/riscv/kvm.c +@@ -99,7 +99,7 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, + + #define KVM_RISCV_SET_TIMER(cs, env, name, reg) \ + do { \ +- int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), ®); \ ++ int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, name), ®); \ + if (ret) { \ + abort(); \ + } \ +``` diff --git a/results/classifier/105/KVM/1699824 b/results/classifier/105/KVM/1699824 new file mode 100644 index 00000000..3393df54 --- /dev/null +++ b/results/classifier/105/KVM/1699824 @@ -0,0 +1,296 @@ +KVM: 0.686 +socket: 0.635 +other: 0.607 +instruction: 0.604 +device: 0.596 +boot: 0.580 +graphic: 0.552 +network: 0.544 +mistranslation: 0.528 +semantic: 0.492 +assembly: 0.478 +vnc: 0.450 + +qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso + +qemu-system-sparc64 qemu-2.9.0-3.10.x86_64 on openSUSE Leap 42.3 using 'sun4v' machine aborts with tribblix. With 2048 MB of RAM it takes considerably more time to abort (but the core is always truncated). + +> qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso -boot d -nographic -M sun4v +qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state +pc: 0000000000000200 npc: 0000000000000204 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l0-3: 000000003ff00000 000001ff00000000 000001fff0080000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8 +tbr: 0000000000000000 hpstate: 0000000000000004 htba: 0000000000000000 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 + +Aborted (core dumped) + + + PID: 26999 (qemu-system-spa) + UID: 1000 (newman) + GID: 100 (users) + Signal: 6 (ABRT) + Timestamp: Thu 2017-06-22 16:19:02 CEST (1min 5s ago) + Command Line: qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso -boot d -nographic -M sun4v + Executable: /usr/bin/qemu-system-sparc64 + Control Group: / + Slice: -.slice + Boot ID: aa7431274f854fb7a02a773eefa8a9bb + Machine ID: 89c660865c00403a9bacef32b6828556 + Hostname: assam.suse.cz + Coredump: /var/lib/systemd/coredump/core.qemu-system-spa.1000.aa7431274f854fb7a02a773eefa8a9bb.26999.1498141142000000.xz + Message: Process 26999 (qemu-system-spa) of user 1000 dumped core. + + + +(gdb) thread apply all bt full + +Thread 4 (Thread 0x7f3896aca700 (LWP 27001)): +#0 0x00007f38bb983295 in do_futex_wait () at /lib64/libpthread.so.0 +#1 0x00007f38bb983349 in __new_sem_wait_slow () at /lib64/libpthread.so.0 +#2 0x00007f38bb9833f7 in sem_timedwait () at /lib64/libpthread.so.0 +#3 0x00005599ec6a1147 in qemu_sem_timedwait (sem=sem@entry=0x5599ef168628, ms=ms@entry=10000) at util/qemu-thread-posix.c:255 + rc = <optimized out> + ts = {tv_sec = 1498141152, tv_nsec = 280531000} + __func__ = "qemu_sem_timedwait" +#4 0x00005599ec69c83c in worker_thread (opaque=0x5599ef1685c0) at util/thread-pool.c:92 + req = <optimized out> + ret = <optimized out> + pool = 0x5599ef1685c0 +#5 0x00007f38bb97c744 in start_thread () at /lib64/libpthread.so.0 +#6 0x00007f38b79bdd3d in clone () at /lib64/libc.so.6 + +Thread 3 (Thread 0x7f38bee01c40 (LWP 26999)): +#0 0x00007f38b79b555f in ppoll () at /lib64/libc.so.6 +#1 0x00005599ec69d289 in ppoll (__ss=0x0, __timeout=0x7ffd1dcf2a20, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77 + ts = {tv_sec = 1, tv_nsec = 0} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x00005599ec69d289 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=1000000000) at util/qemu-timer.c:334 + ts = {tv_sec = 1, tv_nsec = 0} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#3 0x00005599ec69dff8 in os_host_main_loop_wait (timeout=1000000000) at util/main-loop.c:255 + context = 0x5599ef147470 + ret = <optimized out> + spin_counter = 0 + ret = -283872144 + timeout = 1000 +#4 0x00005599ec69dff8 in main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:517 + ret = -283872144 + timeout = 1000 +#5 0x00005599ec3c8c5f in main_loop () at vl.c:1900 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = 0x0 + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + opts = <optimized out> + hda_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 10 + optarg = 0x7ffd1dcf51d2 "sun4v" + loadvm = <optimized out> + machine_class = 0x5599ec6d6f6f + cpu_model = <optimized out> + vga_model = 0x5599ec6d6f81 "std" + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = <optimized out> + nographic = <optimized out> + display_type = <optimized out> + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffd1dcf2ba0} + rlimit_as = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615} + __func__ = "main" + __FUNCTION__ = "main" +#6 0x00005599ec3c8c5f in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4730 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = 0x0 + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + opts = <optimized out> + hda_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 10 + optarg = 0x7ffd1dcf51d2 "sun4v" + loadvm = <optimized out> + machine_class = 0x5599ec6d6f6f + cpu_model = <optimized out> + vga_model = 0x5599ec6d6f81 "std" + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = <optimized out> + nographic = <optimized out> + display_type = <optimized out> + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffd1dcf2ba0} + rlimit_as = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615} + __func__ = "main" + __FUNCTION__ = "main" + +Thread 2 (Thread 0x7f38abf99700 (LWP 27000)): +#0 0x00007f38b79b98e9 in syscall () at /lib64/libc.so.6 +#1 0x00005599ec6a12d6 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /usr/src/debug/qemu-2.9.0/include/qemu/futex.h:26 + value = <optimized out> +#2 0x00005599ec6a12d6 in qemu_event_wait (ev=ev@entry=0x5599ed0f1e40 <rcu_gp_event>) at util/qemu-thread-posix.c:399 + value = <optimized out> +#3 0x00005599ec6b0a78 in wait_for_readers () at util/rcu.c:131 + qsreaders = {lh_first = 0x7f38abf99588} + index = <optimized out> + tmp = <optimized out> +#4 0x00005599ec6b0a78 in synchronize_rcu () at util/rcu.c:162 +#5 0x00005599ec6b0c79 in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:256 + tries = 0 + n = 565 + node = <optimized out> +#6 0x00007f38bb97c744 in start_thread () at /lib64/libpthread.so.0 +#7 0x00007f38b79bdd3d in clone () at /lib64/libc.so.6 + +Thread 1 (Thread 0x7f38962c9700 (LWP 27002)): +#0 0x00007f38b79088d7 in raise () at /lib64/libc.so.6 +#1 0x00007f38b7909caa in abort () at /lib64/libc.so.6 +#2 0x00005599ec3d1125 in cpu_abort (cpu=cpu@entry=0x5599ef16f800, fmt=fmt@entry=0x5599ec6d3388 "Trap 0x%04x while trap level (%d) >= MAXTL (%d), Error state") at /usr/src/debug/qemu-2.9.0/exec.c:962 + ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7f38962c88b0, reg_save_area = 0x7f38962c87d0}} + ap2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f38962c88b0, reg_save_area = 0x7f38962c87d0}} +#3 0x00005599ec4790b8 in sparc_cpu_do_interrupt (cs=0x5599ef16f800) at /usr/src/debug/qemu-2.9.0/target/sparc/int64_helper.c:119 + cpu = 0x5599ef16f800 + __func__ = "sparc_cpu_do_interrupt" + env = 0x5599ef177a98 + intno = 16 + tsptr = 0x6 +#4 0x00005599ec3dcf54 in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5599ef12e000) at /usr/src/debug/qemu-2.9.0/cpu-exec.c:463 + cc = 0x5599ef12e000 + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = <optimized out>} + __FUNCTION__ = "cpu_exec" +#5 0x00005599ec3dcf54 in cpu_exec (cpu=cpu@entry=0x5599ef16f800) at /usr/src/debug/qemu-2.9.0/cpu-exec.c:668 + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = <optimized out>} + __FUNCTION__ = "cpu_exec" +#6 0x00005599ec40796d in tcg_cpu_exec (cpu=0x5599ef16f800) at /usr/src/debug/qemu-2.9.0/cpus.c:1260 + ret = <optimized out> + r = -1775462656 + cpu = 0x5599ef16f800 +#7 0x00005599ec40796d in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.9.0/cpus.c:1355 + r = -1775462656 + cpu = 0x5599ef16f800 +#8 0x00007f38bb97c744 in start_thread () at /lib64/libpthread.so.0 +#9 0x00007f38b79bdd3d in clone () at /lib64/libc.so.6 + + + +Hi Michal, + +Currently the sun4v machine is still at an alpha stage. Artyom has made some good progress on the niagara machine which was merged for the 2.9 release and is able to run several OSs, so please try that and let us know how you get on. + +Note that I generally try and keep the wiki page at http://wiki.qemu.org/Documentation/Platforms/SPARC up-to-date with the latest information so do have a look there to see examples of how to use the niagara machine. + + +ATB, + +Mark. + + +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". Thank you and sorry for the inconvenience. + +Still occurs with latest qemu built as of today. + ✘ ~/qemu qemu-system-sparc64 -cdrom ./tribblix-sparc-0m16.iso -boot d -m 1024 -nographic -machine sun4v +qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state +pc: 0000000000000200 npc: 0000000000000204 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l0-3: 000000003ff00000 000001ff00000000 000001fff0080000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8 +tbr: 0000000000000000 hpstate: 0000000000000004 htba: 0000000000000000 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 + +fish: “qemu-system-sparc64 -cdrom ./tr…” terminated by signal SIGABRT (Abort) + + + +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/260 + + diff --git a/results/classifier/105/KVM/1706058 b/results/classifier/105/KVM/1706058 new file mode 100644 index 00000000..1207a828 --- /dev/null +++ b/results/classifier/105/KVM/1706058 @@ -0,0 +1,110 @@ +KVM: 0.392 +device: 0.172 +mistranslation: 0.170 +vnc: 0.159 +other: 0.144 +boot: 0.102 +network: 0.099 +assembly: 0.091 +socket: 0.086 +semantic: 0.084 +graphic: 0.079 +instruction: 0.075 + +Windows VM crashes when restoring from file if balloon stats polling is enabled + +[Impact] + + * Windows VMs BSOD when restoring from QEMUfile or during live migration if the virtio balloon stats polling is enabled. + +[Test Case] + + * Install a Windows VM with virtio balloon drivers + * Start the VM and enable stats polling [1] + * Save the VM to savefile [2] + * Restore the VM [3] + * Enable stats polling [1] and VM will BSOD + +QMP examples: + [1] {"execute":"qom-set","arguments":{"path":"//machine/i440fx/pci.0/child[7]","property":"guest-stats-polling-interval","value":10}} + [2] {"execute": "migrate", "arguments": {"uri":"exec:gzip -c > /storage/cases/VM/savefiles/testVM3save.gz"}} + [3] {"execute":"migrate-incoming","arguments":{"uri":"exec:gzip -c -d /storage/cases/VM/savefiles/testVM3save.gz"}} + +[Other Info] + + * This has been fixed upstream with commit 4a1e48becab81020adfb74b22c76a595f2d02a01 + +[Regression Potential] + + * + +Please make sure to use the right target for downstream bugs ==> Re-assigned this to qemu-ubuntu + +Thanks Thomas! + +To confirm the issue described in the original fix, I traced the virtio balloon subsystem (using QEMU simpletracing) while the VM: + +1.) Loaded from a QEMUFile +virtio_set_status 0.000 pid=6248 vdev=0x55dcc49cf968 val=0x0 +balloon_event 31433104.748 pid=6248 opaque=0x55dcc49cf968 addr=0x100000000 +virtio_balloon_to_target 341.343 pid=6248 target=0x100000000 num_pages=0x0 +virtio_set_status 5017492.910 pid=6248 vdev=0x55dcc49cf968 val=0x7 +# Driver negotiation finished; running balloon_stats_cb() -> virtqueue_push() +virtqueue_fill 16176215.480 pid=6248 vq=0x55dcc4a4c9b0 elem=0x55dcc49cfa98 len=0x0 idx=0x0 +virtqueue_flush 6.821 pid=6248 vq=0x55dcc4a4c9b0 count=0x1 +virtqueue_flush_vt 2.050 pid=6248 old=0xc4 new=0xc5 inuse=0x1 +virtio_notify 1.380 pid=6248 vdev=0x55dcc49cf968 vq=0x55dcc4a4c9b0 + +Here stats_vq_offset is 0 and elem->index is invalid, making the guest BSOD. + +2.) Booted normally +... +virtio_set_status 0.754 pid=1133 vdev=0x55c2aec27888 val=0x0 +virtio_set_status 21.646 pid=1133 vdev=0x55c2aec27888 val=0x3 +virtio_set_status 297.769 pid=1133 vdev=0x55c2aec27888 val=0x7 +virtio_queue_notify 20.924 pid=1133 vdev=0x55c2aec27888 n=0x2 vq=0x55c2ae39cb60 +virtqueue_pop 29.931 pid=1133 vq=0x55c2ae39cb60 elem=0x55c2aec279b8 in_num=0x0 out_num=0x1 +virtio_balloon_get_config 357.561 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_get_config 10.239 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_get_config 2.862 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_get_config 2.761 pid=1133 num_pages=0x0 acutal=0x0 +virtio_balloon_set_config 171.747 pid=1133 acutal=0x0 oldacutal=0x0 +virtio_balloon_set_config 135.158 pid=1133 acutal=0x0 oldacutal=0x0 +virtio_balloon_set_config 103.806 pid=1133 acutal=0x0 oldacutal=0x0 +virtio_balloon_set_config 95.435 pid=1133 acutal=0x0 oldacutal=0x0 +# Driver negotiation finished; running balloon_stats_cb() -> virtqueue_push() +virtqueue_fill 24115244.041 pid=1133 vq=0x55c2ae39cb60 elem=0x55c2aec279b8 len=0x3c idx=0x0 +virtqueue_flush 7.069 pid=1133 vq=0x55c2ae39cb60 count=0x1 +virtqueue_lol 1.712 pid=1133 old=0x0 new=0x1 inuse=0x1 +virtio_notify 1.120 pid=1133 vdev=0x55c2aec27888 vq=0x55c2ae39cb60 +virtio_queue_notify 1907.429 pid=1133 vdev=0x55c2aec27888 n=0x2 vq=0x55c2ae39cb60 +virtqueue_pop 9.840 pid=1133 vq=0x55c2ae39cb60 elem=0x55c2aec279b8 in_num=0x0 out_num=0x1 +... + +Here stats_vq_offset is 0x3c (the size of stats_vq_elem), and the request proceeds without problem. + +I'm currently working on the SRU + +Thanks Victor for bringing this up and working on it! + +For Documentation, the fix is in qemu 2.8, therefore >=Zesty is good in regard to the bug. + +Parts of the description sounded familiar to me and I found bug 1604010 - this was a rather ugly update regression, so you might want to read through it just to know that context as well. + +Once you have a ppa working please ping me here or on IRC (cpaelzer) so I can give it some extra regressions checks before we push things to the SRU queue. + +Hi Victor, +I'm currently updating bugs on our virt-stack that are open but seem dormant. + +Is work on this going on or is Xenial/Trusty activity that was nominated dropped for a reason? +As I can't reproduce lacking the special guest and env that was needed I'd rely on you to do so. +And since you drove the other fixes for the cloud archive you have the needed changes. + +For now I'm setting these tasks to incomplete to time them out if no feedback was provided when I clear out old bugs the next time. + +Hi Christian, + +Sorry for the lack of updates, I've been trying to reproduce this behavior using Linux guests and it seems that those VMs work perfectly. I'm currently checking the virtio balloon driver for Windows, as it might be the real culprit of the VM crash. + +I'll update the case with my findings, thanks! + diff --git a/results/classifier/105/KVM/1706296 b/results/classifier/105/KVM/1706296 new file mode 100644 index 00000000..f596141e --- /dev/null +++ b/results/classifier/105/KVM/1706296 @@ -0,0 +1,441 @@ +KVM: 0.686 +mistranslation: 0.599 +other: 0.572 +vnc: 0.571 +boot: 0.499 +graphic: 0.492 +device: 0.473 +semantic: 0.460 +instruction: 0.458 +assembly: 0.451 +network: 0.447 +socket: 0.443 + +Booting NT 4 disk causes /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked()) + +Grab the NT 4 disk from https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_227-075-385_CD-KEY_419-1343253_1996 + +Try to boot it as follows: + +qemu-system-x86_64 -hda disk.img -cdrom Microsoft_Windows_NT_Server_Version_4.0_227-075-385_CD-KEY_419-1343253_1996.iso -m 2048 -boot d -machine pc,accel=tcg +WARNING: Image format was not specified for 'disk.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. +** +ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked()) +Aborted (core dumped) + +The stack trace in the failing thread is: + +Thread 4 (Thread 0x7fffb0418700 (LWP 21979)): +#0 0x00007fffdd89b64b in raise () at /lib64/libc.so.6 +#1 0x00007fffdd89d450 in abort () at /lib64/libc.so.6 +#2 0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0 +#3 0x00007fffdff8c7ea in g_assertion_message_expr () + at /lib64/libglib-2.0.so.0 +#4 0x00005555557a7d00 in qemu_mutex_lock_iothread () + at /home/rjones/d/qemu/cpus.c:1580 +#5 0x00005555557cb429 in io_writex (env=env@entry=0x555556751400, iotlbentry=0x55555675b678, + iotlbentry@entry=0x5aaaaae40c918, val=val@entry=8, addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, size=size@entry=4) + at /home/rjones/d/qemu/accel/tcg/cputlb.c:795 +#6 0x00005555557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400) + at /home/rjones/d/qemu/softmmu_template.h:265 +#7 0x00005555557ce0f7 in helper_le_stl_mmu (env=env@entry=0x555556751400, addr=addr@entry=2148532220, val=val@entry=8, oi=<optimized out>, retaddr=93825011136120, retaddr@entry=0) at /home/rjones/d/qemu/softmmu_template.h:300 +#8 0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, ptr=2148532220, v=8, retaddr=0) at /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182 +#9 0x0000555555882610 in do_interrupt_protected (is_hw=<optimized out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>, intno=<optimized out>, env=0x555556751400) at /home/rjones/d/qemu/target/i386/seg_helper.c:758 +#10 0x0000555555882610 in do_interrupt_all (cpu=cpu@entry=0x555556749170, intno=<optimized out>, is_int=<optimized out>, error_code=2, next_eip=<optimized out>, is_hw=is_hw@entry=0) at /home/rjones/d/qemu/target/i386/seg_helper.c:1252 +#11 0x00005555558839d3 in x86_cpu_do_interrupt (cs=0x555556749170) + at /home/rjones/d/qemu/target/i386/seg_helper.c:1298 +#12 0x00005555557d2ccb in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5555566a4590) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:465 +#13 0x00005555557d2ccb in cpu_exec (cpu=cpu@entry=0x555556749170) + at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:670 +#14 0x00005555557a855a in tcg_cpu_exec (cpu=0x555556749170) + at /home/rjones/d/qemu/cpus.c:1270 +#15 0x00005555557a855a in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) + at /home/rjones/d/qemu/cpus.c:1365 +#16 0x00007fffddc3d36d in start_thread () at /lib64/libpthread.so.0 +#17 0x00007fffdd975b9f in clone () at /lib64/libc.so.6 + + +Thomas Huth <email address hidden> writes: + +> On 25.07.2017 11:30, Richard Jones wrote: +>> ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked()) +>> Aborted (core dumped) +>> +>> The stack trace in the failing thread is: +>> +>> Thread 4 (Thread 0x7fffb0418700 (LWP 21979)): +>> #0 0x00007fffdd89b64b in raise () at /lib64/libc.so.6 +>> #1 0x00007fffdd89d450 in abort () at /lib64/libc.so.6 +>> #2 0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0 +>> #3 0x00007fffdff8c7ea in g_assertion_message_expr () +>> at /lib64/libglib-2.0.so.0 +>> #4 0x00005555557a7d00 in qemu_mutex_lock_iothread () +>> at /home/rjones/d/qemu/cpus.c:1580 +>> #5 0x00005555557cb429 in io_writex (env=env@entry=0x555556751400, iotlbentry=0x55555675b678, +>> iotlbentry@entry=0x5aaaaae40c918, val=val@entry=8, addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, size=size@entry=4) +>> at /home/rjones/d/qemu/accel/tcg/cputlb.c:795 +>> #6 0x00005555557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400) +>> at /home/rjones/d/qemu/softmmu_template.h:265 +>> #7 0x00005555557ce0f7 in helper_le_stl_mmu (env=env@entry=0x555556751400, addr=addr@entry=2148532220, val=val@entry=8, oi=<optimized out>, retaddr=93825011136120, retaddr@entry=0) at /home/rjones/d/qemu/softmmu_template.h:300 +>> #8 0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, ptr=2148532220, v=8, retaddr=0) at /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182 +>> #9 0x0000555555882610 in do_interrupt_protected (is_hw=<optimized +>> out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>, +>> intno=<optimized out>, env=0x555556751400) at +>> /home/rjones/d/qemu/target/i386/seg_helper.c:758 + +Erm, what is happening here? I think the seg_helper is writing a stack +frame but for some reason to io memory, triggering the BQL. This just +seems weird. + +>> #10 0x0000555555882610 in do_interrupt_all (cpu=cpu@entry=0x555556749170, intno=<optimized out>, is_int=<optimized out>, error_code=2, next_eip=<optimized out>, is_hw=is_hw@entry=0) at /home/rjones/d/qemu/target/i386/seg_helper.c:1252 +>> #11 0x00005555558839d3 in x86_cpu_do_interrupt (cs=0x555556749170) +>> at /home/rjones/d/qemu/target/i386/seg_helper.c:1298 +>> #12 0x00005555557d2ccb in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5555566a4590) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:465 +>> #13 0x00005555557d2ccb in cpu_exec (cpu=cpu@entry=0x555556749170) +>> at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:670 +>> #14 0x00005555557a855a in tcg_cpu_exec (cpu=0x555556749170) +>> at /home/rjones/d/qemu/cpus.c:1270 +>> #15 0x00005555557a855a in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) +>> at /home/rjones/d/qemu/cpus.c:1365 +>> #16 0x00007fffddc3d36d in start_thread () at /lib64/libpthread.so.0 +>> #17 0x00007fffdd975b9f in clone () at /lib64/libc.so.6 +> +> Looks like the iothread lock is taken twice here, one time in +> accel/tcg/cpu-exec.c around line 465 and one time in +> accel/tcg/cputlb.c:795 again. +> +> If I've get that right, the locks have been added by this commit here: +> +> 8d04fb55dec381bc5105cb47f29d918e579e8cbd +> tcg: drop global lock during TCG code execution +> +> so this looks related to the MTTCG reworks that happened recently. I +> hope one of the MTTCG gurus has some spare time to look at this... + +I think I really need an x86 guru to explain what just happened. + +-- +Alex Bennée + + +On 25 July 2017 at 15:54, Alex Bennée <email address hidden> wrote: +> +> Thomas Huth <email address hidden> writes: +> +>> On 25.07.2017 11:30, Richard Jones wrote: +>>> ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked()) +>>> Aborted (core dumped) +>>> +>>> The stack trace in the failing thread is: +>>> +>>> Thread 4 (Thread 0x7fffb0418700 (LWP 21979)): +>>> #0 0x00007fffdd89b64b in raise () at /lib64/libc.so.6 +>>> #1 0x00007fffdd89d450 in abort () at /lib64/libc.so.6 +>>> #2 0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0 +>>> #3 0x00007fffdff8c7ea in g_assertion_message_expr () +>>> at /lib64/libglib-2.0.so.0 +>>> #4 0x00005555557a7d00 in qemu_mutex_lock_iothread () +>>> at /home/rjones/d/qemu/cpus.c:1580 +>>> #5 0x00005555557cb429 in io_writex (env=env@entry=0x555556751400, iotlbentry=0x55555675b678, +>>> iotlbentry@entry=0x5aaaaae40c918, val=val@entry=8, addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, size=size@entry=4) +>>> at /home/rjones/d/qemu/accel/tcg/cputlb.c:795 +>>> #6 0x00005555557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400) +>>> at /home/rjones/d/qemu/softmmu_template.h:265 +>>> #7 0x00005555557ce0f7 in helper_le_stl_mmu (env=env@entry=0x555556751400, addr=addr@entry=2148532220, val=val@entry=8, oi=<optimized out>, retaddr=93825011136120, retaddr@entry=0) at /home/rjones/d/qemu/softmmu_template.h:300 +>>> #8 0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, ptr=2148532220, v=8, retaddr=0) at /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182 +>>> #9 0x0000555555882610 in do_interrupt_protected (is_hw=<optimized +>>> out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>, +>>> intno=<optimized out>, env=0x555556751400) at +>>> /home/rjones/d/qemu/target/i386/seg_helper.c:758 +> +> Erm, what is happening here? I think the seg_helper is writing a stack +> frame but for some reason to io memory, triggering the BQL. This just +> seems weird. + +Even if this happens because the guest is going haywire, +if the guest can provoke it then we need to handle it +without asserting... + +thanks +-- PMM + + +* Alex Bennée (<email address hidden>) wrote: +> +> Thomas Huth <email address hidden> writes: +> +> > On 25.07.2017 11:30, Richard Jones wrote: +> >> ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked()) +> >> Aborted (core dumped) +> >> +> >> The stack trace in the failing thread is: +> >> +> >> Thread 4 (Thread 0x7fffb0418700 (LWP 21979)): +> >> #0 0x00007fffdd89b64b in raise () at /lib64/libc.so.6 +> >> #1 0x00007fffdd89d450 in abort () at /lib64/libc.so.6 +> >> #2 0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0 +> >> #3 0x00007fffdff8c7ea in g_assertion_message_expr () +> >> at /lib64/libglib-2.0.so.0 +> >> #4 0x00005555557a7d00 in qemu_mutex_lock_iothread () +> >> at /home/rjones/d/qemu/cpus.c:1580 +> >> #5 0x00005555557cb429 in io_writex (env=env@entry=0x555556751400, iotlbentry=0x55555675b678, +> >> iotlbentry@entry=0x5aaaaae40c918, val=val@entry=8, addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, size=size@entry=4) +> >> at /home/rjones/d/qemu/accel/tcg/cputlb.c:795 +> >> #6 0x00005555557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400) +> >> at /home/rjones/d/qemu/softmmu_template.h:265 +> >> #7 0x00005555557ce0f7 in helper_le_stl_mmu (env=env@entry=0x555556751400, addr=addr@entry=2148532220, val=val@entry=8, oi=<optimized out>, retaddr=93825011136120, retaddr@entry=0) at /home/rjones/d/qemu/softmmu_template.h:300 +> >> #8 0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, ptr=2148532220, v=8, retaddr=0) at /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182 +> >> #9 0x0000555555882610 in do_interrupt_protected (is_hw=<optimized +> >> out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>, +> >> intno=<optimized out>, env=0x555556751400) at +> >> /home/rjones/d/qemu/target/i386/seg_helper.c:758 +> +> Erm, what is happening here? I think the seg_helper is writing a stack +> frame but for some reason to io memory, triggering the BQL. This just +> seems weird. + +addr=2148532220 doesn't seem fun; that's 800FFFFC maybe a missing mask +somewhere? +(or cpu in completely the wrong mode). + +Dave + +> +> >> #10 0x0000555555882610 in do_interrupt_all (cpu=cpu@entry=0x555556749170, intno=<optimized out>, is_int=<optimized out>, error_code=2, next_eip=<optimized out>, is_hw=is_hw@entry=0) at /home/rjones/d/qemu/target/i386/seg_helper.c:1252 +> >> #11 0x00005555558839d3 in x86_cpu_do_interrupt (cs=0x555556749170) +> >> at /home/rjones/d/qemu/target/i386/seg_helper.c:1298 +> >> #12 0x00005555557d2ccb in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5555566a4590) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:465 +> >> #13 0x00005555557d2ccb in cpu_exec (cpu=cpu@entry=0x555556749170) +> >> at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:670 +> >> #14 0x00005555557a855a in tcg_cpu_exec (cpu=0x555556749170) +> >> at /home/rjones/d/qemu/cpus.c:1270 +> >> #15 0x00005555557a855a in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) +> >> at /home/rjones/d/qemu/cpus.c:1365 +> >> #16 0x00007fffddc3d36d in start_thread () at /lib64/libpthread.so.0 +> >> #17 0x00007fffdd975b9f in clone () at /lib64/libc.so.6 +> > +> > Looks like the iothread lock is taken twice here, one time in +> > accel/tcg/cpu-exec.c around line 465 and one time in +> > accel/tcg/cputlb.c:795 again. +> > +> > If I've get that right, the locks have been added by this commit here: +> > +> > 8d04fb55dec381bc5105cb47f29d918e579e8cbd +> > tcg: drop global lock during TCG code execution +> > +> > so this looks related to the MTTCG reworks that happened recently. I +> > hope one of the MTTCG gurus has some spare time to look at this... +> +> I think I really need an x86 guru to explain what just happened. +> +> -- +> Alex Bennée +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +There are three possibilities: + +1) push qemu_mutex_lock_iothread down to cc->do_interrupt + +2) change the condition in io_readx/io_writex to mr->global_locking && !qemu_mutex_iothread_locked() + +3) both + +We can do (2) for 2.10 and later ponder on doing the first. + +Using '-cpu 486' gets past the assertion error. I guess Windows NT 4.0 is not compatible with newer Intel processors. + +Currently I can install Windows NT 4.0, but booting from the installation has its problems. It won't boot unless you use the NTFS file system. Even with this file system I still see a BSOD that states INACCESSIBLE_BOOT_DEVICE. Not sure what is wrong. Switching to a SCSI controller didn't help. + +If you forget to add -cpu 486 or -cpu pentium your disk image will be corrupted and the display will display random characters. + +This workaround should help you avoid problems with Windows NT 4.0. + +Create the disk image for the hard drive that is 4GB or less in size: +qemu-img create -f qcow2 <HD image file name>.qcow2 4G + +Run QEMU booting from the CD-ROM. I assume you used the Windows NT 4.0 workstation CD. +qemu-system-i386 -cpu pentium -vga cirrus -hda <HD image file name>.qcow2 -cdrom <path to iso> -boot c + +Note: I used QEMU 2.10 RC3, Commit 1f296733876434118fd766cfef5eb6f29ecab6a8. I know the boot arguments says it will boot from the hard drive but it will still work. The BIOS will see the hard drive can't be booted and will look for another boot device. After the initial install of Windows NT 4.0 you will be required to reboot to continue with more installation. The above command-line allows you to continue with installation without having to quit QEMU. If you choose to use an older version of QEMU you may run into more problems. For example under QEMU 2.8.0 Windows NT 4.0 will think the hard drive is twice the size it really is. This will lead to an unbootable installation. + + + +John Arbuckle <email address hidden> writes: + +> Using '-cpu 486' gets past the assertion error. I guess Windows NT 4.0 +> is not compatible with newer Intel processors. + +It might be related. The assertion error is caused by the fact an +exception has occurred and processor is trying to dump a stack frame that +overlaps from RAM into device memory. As the IRQ/exception handling is +already under the BQL (as it changes machine state) we get the assertion +when it tries to take the BQL a second time when accessing device +memory. + +We can drop the lock in the stack frame writing code but I don't know +what effect that would have as the guest still might crash having tried +to write a stack frame to device memory.... + +> +> Currently I can install Windows NT 4.0, but booting from the +> installation has its problems. It won't boot unless you use the NTFS +> file system. Even with this file system I still see a BSOD that states +> INACCESSIBLE_BOOT_DEVICE. Not sure what is wrong. Switching to a SCSI +> controller didn't help. + + +-- +Alex Bennée + + +On 18 August 2017 at 09:40, Alex Bennée <email address hidden> wrote: +> +> John Arbuckle <email address hidden> writes: +> +>> Using '-cpu 486' gets past the assertion error. I guess Windows NT 4.0 +>> is not compatible with newer Intel processors. +> +> It might be related. The assertion error is caused by the fact an +> exception has occurred and processor is trying to dump a stack frame that +> overlaps from RAM into device memory. As the IRQ/exception handling is +> already under the BQL (as it changes machine state) we get the assertion +> when it tries to take the BQL a second time when accessing device +> memory. + +This sounds worrying -- lots and lots of target backend code +does writes to memory. Is it all going to cause assertions if +it happens to be pointing at a device? + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On 18 August 2017 at 09:40, Alex Bennée <email address hidden> wrote: +>> +>> John Arbuckle <email address hidden> writes: +>> +>>> Using '-cpu 486' gets past the assertion error. I guess Windows NT 4.0 +>>> is not compatible with newer Intel processors. +>> +>> It might be related. The assertion error is caused by the fact an +>> exception has occurred and processor is trying to dump a stack frame that +>> overlaps from RAM into device memory. As the IRQ/exception handling is +>> already under the BQL (as it changes machine state) we get the assertion +>> when it tries to take the BQL a second time when accessing device +>> memory. +> +> This sounds worrying -- lots and lots of target backend code +> does writes to memory. Is it all going to cause assertions if +> it happens to be pointing at a device? + +Currently yes. + +That said from John's update it sounds very much like a symptom of not +emulating the right processor type rather than behaviour we are +incorrectly modelling. If we invert the lock before writing the stack +page is it just going to crash in a more esoteric way? + +I'm not sure how you correctly emulate writing random stack pages to a +random device. Unless there is some sort of weird [un]documented behaviour +we should be doing? + +-- +Alex Bennée + + +On 18 August 2017 at 11:23, Alex Bennée <email address hidden> wrote: +> Peter Maydell <email address hidden> writes: +>> On 18 August 2017 at 09:40, Alex Bennée <email address hidden> wrote: +>>> It might be related. The assertion error is caused by the fact an +>>> exception has occurred and processor is trying to dump a stack frame that +>>> overlaps from RAM into device memory. As the IRQ/exception handling is +>>> already under the BQL (as it changes machine state) we get the assertion +>>> when it tries to take the BQL a second time when accessing device +>>> memory. +>> +>> This sounds worrying -- lots and lots of target backend code +>> does writes to memory. Is it all going to cause assertions if +>> it happens to be pointing at a device? +> +> Currently yes. +> +> That said from John's update it sounds very much like a symptom of not +> emulating the right processor type rather than behaviour we are +> incorrectly modelling. If we invert the lock before writing the stack +> page is it just going to crash in a more esoteric way? +> +> I'm not sure how you correctly emulate writing random stack pages to a +> random device. Unless there is some sort of weird [un]documented behaviour +> we should be doing? + +The desired behaviour is straightforward -- if the code calls +a function for "do a 4 byte write" then we do a 4 byte write +to the device. The only place where writing to a device has +to be special cased is when we're trying to execute code +from it (which is itself arguably a defect of our emulation). + +It looks like we only get this double locking when the +target/ code does a write-by-virtual-address (which ends +up going via io_writex() which takes the lock again) -- +write-by-physical-address, eg stl_phys and friends presumably +don't take the lock. That's a rather confusing mismatch of +semantics. + +thanks +-- PMM + + +On Fri, Aug 18, 2017 at 10:23:25AM -0000, Alex Bennée wrote: +> That said from John's update it sounds very much like a symptom of not +> emulating the right processor type rather than behaviour we are +> incorrectly modelling. + +FWIW I checked back with the original specs, and NT 4.0 minimally +required a Pentium processor (and 16 MB of RAM :-) + +Rich. + +-- +Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones +Read my programming and virtualization blog: http://rwmj.wordpress.com +virt-df lists disk usage of guests without needing to install any +software inside the virtual machine. Supports Linux and Windows. +http://people.redhat.com/~rjones/virt-df/ + + +On 18 August 2017 at 11:23, Alex Bennée <email address hidden> wrote: +> If we invert the lock before writing the stack +> page is it just going to crash in a more esoteric way? + +Paolo suggested a straightforward fix for 2.10 (which we unfortunately +never did :-() which we could use to check this theory. + +thanks +-- PMM + + +Actually Windows NT 4.0 requires a 486 or higher. https://en.wikipedia.org/wiki/Windows_NT + +Found out that the qcow2 image format causes INACCESSIBLE_BOOT_DEVICE errors with Windows NT 4.0, so I am going to update my workaround to use the qcow format instead. + +qemu-img create -f qcow <HD image file name>.qcow 4G + +qemu-system-i386 -cpu pentium -vga cirrus -hda <HD image file name>.qcow -cdrom <path to iso> -boot c + +Was this ever fixed in QEMU, or can the issue still be reproduced in the latest version? + +commit 8b81253332b5a3f claims in its subject line that it "fixes #1706296", and it implements Paolo's option (2) from comment #4. So I'd go with "already fixed". The bug has a simple reproducer in the report though, so it's also easy to test... + + +With the original repro command line, the guest now crashes "cleanly", ie without triggering a QEMU assert. If you give the guest a CPU type it recognizes, eg '-cpu pentium' (as noted in comment 7) then it boots OK, at least to the point of user control in the installer. So I think this is fixed. + + + diff --git a/results/classifier/105/KVM/1709784 b/results/classifier/105/KVM/1709784 new file mode 100644 index 00000000..158edc2a --- /dev/null +++ b/results/classifier/105/KVM/1709784 @@ -0,0 +1,346 @@ +KVM: 0.867 +mistranslation: 0.843 +vnc: 0.798 +graphic: 0.730 +other: 0.709 +instruction: 0.708 +device: 0.684 +boot: 0.653 +semantic: 0.633 +assembly: 0.612 +network: 0.598 +socket: 0.582 + +KVM on 16.04.3 throws an error + +Problem Description +==================== +KVM on Ubuntu 16.04.3 throws an error when used + +---uname output--- +Linux bastion-1 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31 19:37:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux + +Machine Type = 8348-21C Habanero + +---Steps to Reproduce--- + Install 16.04.3 + +install KVM like: + +apt-get install libvirt-bin qemu qemu-slof qemu-system qemu-utils + +then exit and log back in so virsh will work without sudo + +then run my spawn script + +$ cat spawn.sh +#!/bin/bash + +img=$1 +qemu-system-ppc64 \ +-machine pseries,accel=kvm,usb=off -cpu host -m 512 \ +-display none -nographic \ +-net nic -net user \ +-drive "file=$img" + +with a freshly downloaded ubuntu cloud image + +sudo ./spawn.sh xenial-server-cloudimg-ppc64el-disk1.img + +And I get nothing on the output. + +and errors in dmesg + + +ubuntu@bastion-1:~$ [ 340.180295] Facility 'TM' unavailable, exception at 0xd0000000148b7f10, MSR=9000000000009033 +[ 340.180399] Oops: Unexpected facility unavailable exception, sig: 6 [#1] +[ 340.180513] SMP NR_CPUS=2048 NUMA PowerNV +[ 340.180547] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv kvm binfmt_misc joydev input_leds mac_hid opal_prd ofpart cmdlinepart powernv_flash ipmi_powernv ipmi_msghandler mtd at24 uio_pdrv_genirq uio ibmpowernv powernv_rng vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear mlx4_en hid_generic usbhid hid uas usb_storage ast i2c_algo_bit bnx2x ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops mlx4_core drm ahci vxlan libahci ip6_udp_tunnel udp_tunnel mdio libcrc32c +[ 340.181331] CPU: 46 PID: 5252 Comm: qemu-system-ppc Not tainted 4.4.0-89-generic #112-Ubuntu +[ 340.181382] task: c000001e34c30b50 ti: c000001e34ce4000 task.ti: c000001e34ce4000 +[ 340.181432] NIP: d0000000148b7f10 LR: d000000014822a14 CTR: d0000000148b7e40 +[ 340.181475] REGS: c000001e34ce77b0 TRAP: 0f60 Not tainted (4.4.0-89-generic) +[ 340.181519] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 22024848 XER: 00000000 +[ 340.181629] CFAR: d0000000148b7ea4 SOFTE: 1 +GPR00: d000000014822a14 c000001e34ce7a30 d0000000148cc018 c000001e37bc0000 +GPR04: c000001db9ac0000 c000001e34ce7bc0 0000000000000000 0000000000000000 +GPR08: 0000000000000001 c000001e34c30b50 0000000000000001 d0000000148278f8 +GPR12: d0000000148b7e40 c00000000fb5b500 0000000000000000 000000000000001f +GPR16: 00003fff91c30000 0000000000800000 00003fffa8e34390 00003fff9242f200 +GPR20: 00003fff92430010 000001001de5c030 00003fff9242eb60 00000000100c1ff0 +GPR24: 00003fffc91fe990 00003fff91c10028 0000000000000000 c000001e37bc0000 +GPR28: 0000000000000000 c000001db9ac0000 c000001e37bc0000 c000001db9ac0000 +[ 340.182315] NIP [d0000000148b7f10] kvmppc_vcpu_run_hv+0xd0/0xff0 [kvm_hv] +[ 340.182357] LR [d000000014822a14] kvmppc_vcpu_run+0x44/0x60 [kvm] +[ 340.182394] Call Trace: +[ 340.182413] [c000001e34ce7a30] [c000001e34ce7ab0] 0xc000001e34ce7ab0 (unreliable) +[ 340.182468] [c000001e34ce7b70] [d000000014822a14] kvmppc_vcpu_run+0x44/0x60 [kvm] +[ 340.182522] [c000001e34ce7ba0] [d00000001481f674] kvm_arch_vcpu_ioctl_run+0x64/0x170 [kvm] +[ 340.182581] [c000001e34ce7be0] [d000000014813918] kvm_vcpu_ioctl+0x528/0x7b0 [kvm] +[ 340.182634] [c000001e34ce7d40] [c0000000002fffa0] do_vfs_ioctl+0x480/0x7d0 +[ 340.182678] [c000001e34ce7de0] [c0000000003003c4] SyS_ioctl+0xd4/0xf0 +[ 340.182723] [c000001e34ce7e30] [c000000000009204] system_call+0x38/0xb4 +[ 340.182766] Instruction dump: +[ 340.182788] e92d02a0 e9290a50 e9290108 792a07e3 41820058 e92d02a0 e9290a50 e9290108 +[ 340.182863] 7927e8a4 78e71f87 40820ed8 e92d02a0 <7d4022a6> f9490ee8 e92d02a0 7d4122a6 +[ 340.182938] ---[ end trace bc5080cb7d18f102 ]--- +[ 340.276202] + + +This was with the latest ubuntu cloud image. I get the same thing when trying to use virt-install with an ISO image. + +I have no way of loading a KVM on 16.04.3 + +== Comment: #2 - Jason M. Furmanek <email address hidden> - 2017-08-09 17:42:34 == +I reinstalled with the HWE kernel (4.10). +I can install VM and see the console and eveything seems fine. + +== Comment: #3 - Jason M. Furmanek <email address hidden> - 2017-08-09 17:44:03 == +I had another system at 16.04.2 (4.4) and updated that one to the latest and it hit the same issue as above. +No qemu or libvirt updates were applied. Just kernel updates and a handful of other stuff. + +Seems this issue is specific to the latest kernel + +old version worked: +Linux fs7 4.4.0-83-generic #106 + +new version did not: +Linux fs7 4.4.0-89-generic #112-Ubuntu + +== Comment: #4 - Gustavo Bueno Romero <email address hidden> - 2017-08-09 20:26:42 == +Looks like 46a704f8409f79fd66567ad3f8a7304830a84293 was backported on 88 but e47057151422a67ce08747176fa21cb3b526a2c9 was not: + +[gromero@localhost ubuntu-xenial]$ git remote -vv +origin git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git (fetch) +origin git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git (push) + +[gromero@localhost ubuntu-xenial]$ git log Ubuntu-4.4.0-83.106..Ubuntu-4.4.0-89.112 --oneline | fgrep "Preserve userspace HTM state properly" +a97e978 KVM: PPC: Book3S HV: Preserve userspace HTM state properly +[gromero@localhost ubuntu-xenial]$ git log Ubuntu-4.4.0-83.106..Ubuntu-4.4.0-89.112 --oneline | fgrep "Enable TM before accessing TM registers" +[gromero@localhost ubuntu-xenial]$ git tag --contains a97e978574f41ffcf1813c180aba2772d46fbb5b +Ubuntu-4.4.0-88.111 +Ubuntu-4.4.0-89.112 +Ubuntu-raspi2-4.4.0-1066.74 +Ubuntu-raspi2-4.4.0-1067.75 +Ubuntu-snapdragon-4.4.0-1068.73 +Ubuntu-snapdragon-4.4.0-1069.74 + +So +https://github.com/torvalds/linux/commit/46a704f8409f79fd66567ad3f8a7304830a84293 is present in ISO but https://github.com/torvalds/linux/commit/e47057151422a67ce08747176fa21cb3b526a2c9 is not. + +Hi, +there was a related case in bug 1664622. + +The TL;DR of this was: +1. even with all qemu patches identified by IBM and upstream while working on this the issue still showed up. +2. newer kernels (>=4.8, but also newer 4.4 kernels than those on the release itself worked - that matches the report here) +3. the conclusion was that nothing can/has-to be done for qemu [1] +4. there was no way to fix the initial 16.04.0 iso, but that was considered ok since 16.04.2 worked + +Mapping to this bug here it seems that a further update to 4.4 might have broken it "again" as identified by Gustavo in in this report. + +I added all this to complete the context for everybody else, but for now qemu stays at won't fix for the reasons and assumptions haven't changed since our last check on this issue. + +On the kernel surely if the identified two patches really need to go together a fix might be needed, but that is for the kernel Team to evaluate. + +[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1664622/comments/27 + +Thanks Christian. Reassigning to kernel team. + +I built test kernels with a pick of commit e47057151422. The test kernels can be downloaded from: + +Xenial: http://kernel.ubuntu.com/~jsalisbury/lp1709784/xenial/ +Zesty: http://kernel.ubuntu.com/~jsalisbury/lp1709784/zesty/ + + +Can you test these kernels and see if they resolve this bug? + +Thanks in advance! + +I just tested zesty kernel and it worked fine: + +# uname -a +Linux sid 4.10.0-30-generic #34~lp1709784 SMP Thu Aug 10 20:01:17 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux + +# sudo virsh list + Id Name State +---------------------------------------------------- + 1 unstable running + 2 debian running + 4 1604 running + +# sudo virsh console 1604 +Connected to domain 1604 +Escape character is ^] + +Ubuntu 16.04.3 LTS 1604 hvc0 + +1604 login: + + + +I also tested xenial GA kernel: + +sid ➜ ~ sudo uname -a +Linux sid 4.4.0-89-generic #112~lp1709784 SMP Thu Aug 10 19:39:43 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux + +sid ➜ ~ sudo virsh list + Id Name State +---------------------------------------------------- + 2 debian running + 3 1604 running + 4 unstable running + +sid ➜ ~ sudo virsh console 1604 +Connected to domain 1604 +Escape character is ^] + +Ubuntu 16.04.3 LTS 1604 hvc0 + +1604 login: + + +Thanks for testing. I'll submit SRU requests for both Zesty and Xenial. + +There is commit 17d381054b1d6f4adc3db623b2066fff41b4dc1a ("KVM: PPC: Book3S HV: Reload HTM registers explicitly") from +v4.4.80 series that is in Xenial master-next. I built a master-next test kernel, which can be downloaded from: + +Xenial: http://kernel.ubuntu.com/~jsalisbury/lp1709784/xenial/ + +Can you test these kernels and see if they resolve this bug? + +Thanks in advance! + +I ran into this issue as well, and confirmed with the kernel built above (http://kernel.ubuntu.com/~jsalisbury/lp1709784/xenial/) that things now work again. Thanks! + +------- Comment From <email address hidden> 2017-09-01 00:40 EDT------- +I tested the test kernel made available by jsalisbury and it worked for me as well. + +This is a pretty big blocker - very much hoping this makes it into a new kernel soon. + +@furmanek, The fix is in the Ubuntu-4.4.0-94 kernel, which is the current -proposed kernel. + +Would it be possible for you to test the proposed kernel and post back if it resolves this bug? +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. + +------- Comment From <email address hidden> 2017-09-04 19:23 EDT------- +Hi jsalisbury, + +linux-image-4.4.0-94-generic from -proposed looks fine to me. VMs boot ok and as expected no TRAP 0xF60 (Facility Unavailable) in dmesg: + +root@sid:~# apt-get -t xenial-proposed install linux-image-4.4.0-94-generic +<REBOOT> +root@sid:~# uname -a +Linux sid 4.4.0-94-generic #117-Ubuntu SMP Tue Aug 29 08:13:18 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux +root@sid:/# dmesg | fgrep 0f60 +root@sid:/# virsh list +Id Name State +---------------------------------------------------- +1 debian running +2 1604 running +4 unstable running + +root@sid:/# virsh console 2 +Connected to domain 1604 +Escape character is ^] + +Ubuntu 16.04.3 LTS 1604 hvc0 + +1604 login: ubuntu +Password: +Last login: Mon Aug 14 15:41:29 EDT 2017 from 10.1.0.1 on pts/0 +Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.10.0-30-generic ppc64le) + +* Documentation: https://help.ubuntu.com +* Management: https://landscape.canonical.com +* Support: https://ubuntu.com/advantage +You have new mail. +1604 ? ~ + +I understand that no further action from IBM is necessary now. Please, let me know if it's not true. + +BTW, do you know when this will likely reach the SRU? + +Thanks a lot and best regards, +Gustavo + +------- Comment From <email address hidden> 2017-09-04 20:46 EDT------- +Only to let you know that I just tested this version successfully as well. + +Thanks! + +Jose Ziviani + +There seems to be an update-regression in Artful. + +Booting a recent Artful guest now again also throws: +[485006.367929] Facility 'TM' unavailable, exception at 0xd000000021617f10, MSR=9000000000009033 +[485006.367943] Oops: Unexpected facility unavailable exception, sig: 6 [#14] +[485006.367945] SMP NR_CPUS=2048 NUMA PowerNV + +Booting a Zesty guest triggers the same. + +Guest kernel(s): 4.12.0.13.14 / 4.10.0.33.33 +Host kernel: 4.4.0-93-generic + +I thought this only triggers if the guest kernel versions is a bad one. +It seems the host kernel (-93 as shown above) also needing to upgrade to avoid the issue? +Ok that makes it worse than I thought - can't reboot to test from proposed atm. + +------- Comment From <email address hidden> 2017-09-12 04:23 EDT------- +*** Bug 158561 has been marked as a duplicate of this bug. *** + +Affects OpenStack on ppc64el. Marking other bug as duplicate (it has logs/attachments fyi). + https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1716469 + +Confirmed workaround for OpenStack Ocata on Xenial: + +### Nova compute host [hwe-edge kernel via MAAS] +ubuntu@node-mawhile:~$ uname -a +Linux node-mawhile 4.11.0-14-generic #20~16.04.1-Ubuntu SMP Wed Aug 9 09:06:18 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux + +### Nova guest [stock xenial ppc64el cloud image] +[ 0.000000] Linux version 4.4.0-65-generic (buildd@bos01-ppc64el-028) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #86-Ubuntu SMP Thu Feb 23 17:48:50 UTC 2017 (Ubuntu 4.4.0-65.86-gene +ric 4.4.49) + +Christian, + +I am looking at 4.4 git repository and version -93 contains exactly the problem described here, it contains the commit# 46a704f8409f79fd66567ad3f8a7304830a84293 (as a97e978574f41ffcf1813c180aba2772d46fbb5b), but it does not include commit# e47057151422a67ce08747176fa21cb3b526a2c9. + +That said, we probably want to include e47057151422a67ce08747176fa21cb3b526a2c9 into 4.4 series as soon as possible. + +------- Comment From <email address hidden> 2017-09-19 16:53 EDT------- +I've tested the new kernel 4.4.0-96 and it fixes this issue. + +Thank you! + +@furmanek, Thanks for testing. + +@Breno, Commit e47057151 was not applied to Xenial. It did not apply cleanly because the following commit is already in Xenial as of 4.4.0-96(As Xenial SHA1 25e0720): + +17d381054b1d6f4adc3db623b2066fff41b4dc1a +("KVM: PPC: Book3S HV: Reload HTM registers explicitly") + + +Commit 17d381054 came in from the 4.4.80 updates and does what commit e47057151 does and more. Per comment #18, it sounds like it fixes this bug. It would be great if others affected by this bug could also test -proposed. + +------- Comment From <email address hidden> 2017-09-20 08:53 EDT------- +> @Breno, Commit e47057151 was not applied to Xenial. It did not apply +> cleanly because the following commit is already in Xenial as of 4.4.0-96(As +> Xenial SHA1 25e0720): +> +> 17d381054b1d6f4adc3db623b2066fff41b4dc1a +> ("KVM: PPC: Book3S HV: Reload HTM registers explicitly") +> +> Commit 17d381054 came in from the 4.4.80 updates and does what commit +> e47057151 does and more. Per comment #18, it sounds like it fixes this bug. +> It would be great if others affected by this bug could also test -proposed. + +Sure. We will let you know if we hit this issue on kernel 4.4.0-96+. + +Thanks + +Based on comments above, moving to "Fix Released". If this issue re-occurs, please update with a new comment. + +As this ticket only relates to Xenial and 4.4 kernel, marking as "Fix Released". + diff --git a/results/classifier/105/KVM/1715203 b/results/classifier/105/KVM/1715203 new file mode 100644 index 00000000..4373aa39 --- /dev/null +++ b/results/classifier/105/KVM/1715203 @@ -0,0 +1,329 @@ +KVM: 0.873 +other: 0.841 +graphic: 0.812 +semantic: 0.806 +vnc: 0.800 +assembly: 0.794 +device: 0.785 +instruction: 0.779 +network: 0.766 +boot: 0.731 +socket: 0.721 +mistranslation: 0.613 + +Maintain Haiku support + +It was pointed out that the 2.10 release notes are pushing to drop Haiku support. The qemu port is currently working as-is under Haiku. + +Was there a reason this was recommended? Is there anything Haiku can do to keep it from being dropped? + +We're working on a docker container to cross-compile rust-lang for Haiku, could this be of some use to qemu when complete? + +On 5 September 2017 at 18:55, kallisti5 <email address hidden> wrote: +> It was pointed out that the 2.10 release notes are pushing to drop Haiku +> support. The qemu port is currently working as-is under Haiku. +> +> Was there a reason this was recommended? Is there anything Haiku can do +> to keep it from being dropped? + +Basically we don't want to try to support host systems where we +have no access to hardware that will let us compile and run +the test suite, and where there's nobody interacting with us +upstream to help fix issues that are Haiku related. + +If there's genuinely a community of Haiku QEMU users out there +who want to help us maintain the support in the QEMU codebase that's +great. What we don't want is to be carrying around code we can't +test and where we don't seem to have anybody using it. (For instance +we're about to drop support for AIX...) + +> We're working on a docker container to cross-compile rust-lang for +> Haiku, could this be of some use to qemu when complete? + +Cross-compilation won't let us run the test suite. + +thanks +-- PMM + + +Haiku recently got a virtio driver, so running a Haiku system in cloud infrastructure seems possible now. (I've personally run it on vultr.com) Does QEMU have some infrastructure available so we can stand up a x86_64 system? + +On 5 September 2017 at 19:14, kallisti5 <email address hidden> wrote: +> Haiku recently got a virtio driver, so running a Haiku system in cloud +> infrastructure seems possible now. (I've personally run it on vultr.com) +> Does QEMU have some infrastructure available so we can stand up a x86_64 +> system? + +Nope. We would be looking either for ssh login on a system somebody +else admins, or detailed instructions on how to set up a VM for it, +like the ones we have for BSD at https://wiki.qemu.org/index.php/Hosts/BSD + +thanks +-- PMM + + +Contacting our board of directors to see if I can get a VM deployed at Vultr. I'll keep this ticket updated. + +We're purchasing some new hardware, once we get it set up we'll setup a x86_64 Haiku machine to build qemu. + +Is there any update on this? Could you provide a machine with ssh login to the QEMU project where QEMU could be built and tested on Haiku? Or can Haiku be installed automatically without graphical UI interactions? In that case, would it be feasible that you provide a VM setup for our tests/vm/ files in QEMU? + +Hi! + +Sorry, I forgot about this one. + +Haiku has a lot of options.. we can setup a vm image if needed to move this along. +Haiku is graphical, but has ssh and all the standard tools. + +Vagrant also supports Haiku and provides some automation around it. +https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&provider=&q=haiku-os + +Let me check out tests/vm/ to see if I can PR something. + +ok.. a Haiku vm for QEMU is WIP here: + +https://github.com/kallisti5/qemu/tree/haiku-test-vm + + + +``` +$ ./haiku.x86_64 --build-image --image /tmp/haiku.img +### Downloading disk image ... +### Preparing disk image ... +./box.img +100% repochecksum-1 [65 bytes] +Validating checksum for Haiku...done. +100% repocache-2 [4.25 KiB] +Validating checksum for Haiku...done. +100% repochecksum-1 [64 bytes] +Validating checksum for HaikuPorts...done. +100% repocache-2 [1.26 MiB] +Validating checksum for HaikuPorts...done. +The following changes will be made: + in system: + install package bzip2_devel-1.0.8-1 from repository HaikuPorts + install package libgpg_error_devel-1.36-1 from repository HaikuPorts + install package gettext-0.19.8.1-7 from repository HaikuPorts + install package ncurses6_devel-6.2-1 from repository HaikuPorts + install package libtasn1_devel-4.15.0-1 from repository HaikuPorts + install package capstone-4.0.2-1 from repository HaikuPorts + install package dtc-1.4.7-2 from repository HaikuPorts + install package libffi_devel-3.2.1-6 from repository HaikuPorts + install package libpcre_devel-8.44-1 from repository HaikuPorts + install package libiconv_devel-1.16-1 from repository HaikuPorts + install package lzo-2.10-2 from repository HaikuPorts + install package nettle-3.5.1-1 from repository HaikuPorts + install package pixman-0.38.4-1 from repository HaikuPorts + install package snappy-1.1.7-2 from repository HaikuPorts + install package libssh2-1.9.0-2 from repository HaikuPorts + install package libusb-1.0.23-1 from repository HaikuPorts + install package p11_kit-0.23.18.1-1 from repository HaikuPorts + install package libunistring-0.9.10-1 from repository HaikuPorts + install package libidn2-2.0.5-1 from repository HaikuPorts + install package libtool_libltdl-2.4.6-2 from repository HaikuPorts + install package file_data-5.38-1 from repository HaikuPorts + install package libgcrypt_devel-1.8.5-1 from repository HaikuPorts + install package glib2-2.62.0-3 from repository HaikuPorts + install package capstone_devel-4.0.2-1 from repository HaikuPorts + install package dtc_devel-1.4.7-2 from repository HaikuPorts + install package lzo_devel-2.10-2 from repository HaikuPorts + install package nettle_devel-3.5.1-1 from repository HaikuPorts + install package pixman_devel-0.38.4-1 from repository HaikuPorts + install package snappy_devel-1.1.7-2 from repository HaikuPorts + install package libssh2_devel-1.9.0-2 from repository HaikuPorts + install package libusb_devel-1.0.23-1 from repository HaikuPorts + install package p11_kit_devel-0.23.18.1-1 from repository HaikuPorts + install package gnutls-3.6.10-2 from repository HaikuPorts + install package libsdl2-2.0.10-1 from repository HaikuPorts + install package file-5.38-1 from repository HaikuPorts + install package gnutls_devel-3.6.10-2 from repository HaikuPorts + install package libsdl2_devel-2.0.10-1 from repository HaikuPorts + install package python3-3.7.7-2 from repository HaikuPorts + install package glib2_devel-2.62.0-3 from repository HaikuPorts +Continue? [yes/no] (yes) : yes +100% bzip2_devel-1.0.8-1-x86_64.hpkg [119.14 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/bzip2_devel-1.0.8-1-x86_64.hpkg...done. +100% libgpg_error_devel-1.36-1-x86_64.hpkg [57.73 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libgpg_error_devel-1.36-1-x86_64.hpkg...done. +100% gettext-0.19.8.1-7-x86_64.hpkg [12.16 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gettext-0.19.8.1-7-x86_64.hpkg...done. +100% ncurses6_devel-6.2-1-x86_64.hpkg [844.82 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/ncurses6_devel-6.2-1-x86_64.hpkg...done. +100% libtasn1_devel-4.15.0-1-x86_64.hpkg [166.87 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libtasn1_devel-4.15.0-1-x86_64.hpkg...done. +100% capstone-4.0.2-1-x86_64.hpkg [1.80 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/capstone-4.0.2-1-x86_64.hpkg...done. +100% dtc-1.4.7-2-x86_64.hpkg [142.38 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/dtc-1.4.7-2-x86_64.hpkg...done. +100% libffi_devel-3.2.1-6-x86_64.hpkg [31.88 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libffi_devel-3.2.1-6-x86_64.hpkg...done. +100% libpcre_devel-8.44-1-x86_64.hpkg [1.26 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libpcre_devel-8.44-1-x86_64.hpkg...done. +100% libiconv_devel-1.16-1-x86_64.hpkg [901.83 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libiconv_devel-1.16-1-x86_64.hpkg...done. +100% lzo-2.10-2-x86_64.hpkg [166.74 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/lzo-2.10-2-x86_64.hpkg...done. +100% nettle-3.5.1-1-x86_64.hpkg [890.41 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/nettle-3.5.1-1-x86_64.hpkg...done. +100% pixman-0.38.4-1-x86_64.hpkg [1.43 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/pixman-0.38.4-1-x86_64.hpkg...done. +100% snappy-1.1.7-2-x86_64.hpkg [34.08 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/snappy-1.1.7-2-x86_64.hpkg...done. +100% libssh2-1.9.0-2-x86_64.hpkg [423.77 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libssh2-1.9.0-2-x86_64.hpkg...done. +100% libusb-1.0.23-1-x86_64.hpkg [50.38 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libusb-1.0.23-1-x86_64.hpkg...done. +100% p11_kit-0.23.18.1-1-x86_64.hpkg [987.54 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/p11_kit-0.23.18.1-1-x86_64.hpkg...done. +100% libunistring-0.9.10-1-x86_64.hpkg [610.86 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libunistring-0.9.10-1-x86_64.hpkg...done. +100% libidn2-2.0.5-1-x86_64.hpkg [196.76 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libidn2-2.0.5-1-x86_64.hpkg...done. +100% libtool_libltdl-2.4.6-2-x86_64.hpkg [64.24 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libtool_libltdl-2.4.6-2-x86_64.hpkg...done. +100% file_data-5.38-1-any.hpkg [300.96 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/file_data-5.38-1-any.hpkg...done. +100% libgcrypt_devel-1.8.5-1-x86_64.hpkg [158.77 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libgcrypt_devel-1.8.5-1-x86_64.hpkg...done. +100% glib2-2.62.0-3-x86_64.hpkg [4.10 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/glib2-2.62.0-3-x86_64.hpkg...done. +100% capstone_devel-4.0.2-1-x86_64.hpkg [1.03 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/capstone_devel-4.0.2-1-x86_64.hpkg...done. +100% dtc_devel-1.4.7-2-x86_64.hpkg [88.46 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/dtc_devel-1.4.7-2-x86_64.hpkg...done. +100% lzo_devel-2.10-2-x86_64.hpkg [314.15 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/lzo_devel-2.10-2-x86_64.hpkg...done. +100% nettle_devel-3.5.1-1-x86_64.hpkg [39.87 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/nettle_devel-3.5.1-1-x86_64.hpkg...done. +100% pixman_devel-0.38.4-1-x86_64.hpkg [1.81 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/pixman_devel-0.38.4-1-x86_64.hpkg...done. +100% snappy_devel-1.1.7-2-x86_64.hpkg [8.90 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/snappy_devel-1.1.7-2-x86_64.hpkg...done. +100% libssh2_devel-1.9.0-2-x86_64.hpkg [51.70 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libssh2_devel-1.9.0-2-x86_64.hpkg...done. +100% libusb_devel-1.0.23-1-x86_64.hpkg [378.12 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libusb_devel-1.0.23-1-x86_64.hpkg...done. +100% p11_kit_devel-0.23.18.1-1-x86_64.hpkg [19.07 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/p11_kit_devel-0.23.18.1-1-x86_64.hpkg...done. +100% gnutls-3.6.10-2-x86_64.hpkg [1.52 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gnutls-3.6.10-2-x86_64.hpkg...done. +100% libsdl2-2.0.10-1-x86_64.hpkg [2.29 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libsdl2-2.0.10-1-x86_64.hpkg...done. +100% file-5.38-1-x86_64.hpkg [103.26 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/file-5.38-1-x86_64.hpkg...done. +100% gnutls_devel-3.6.10-2-x86_64.hpkg [285.23 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gnutls_devel-3.6.10-2-x86_64.hpkg...done. +100% libsdl2_devel-2.0.10-1-x86_64.hpkg [294.06 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libsdl2_devel-2.0.10-1-x86_64.hpkg...done. +100% python3-3.7.7-2-x86_64.hpkg [9.85 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/python3-3.7.7-2-x86_64.hpkg...done. +100% glib2_devel-2.62.0-3-x86_64.hpkg [395.96 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/glib2_devel-2.62.0-3-x86_64.hpkg...done. +[system] Applying changes ... +[system] Changes applied. Old activation state backed up in "state_2020-09-05_14:46:23" +[system] Cleaning up ... +[system] Done. +### All done ... +``` + +$ ./haiku.x86_64 --verbose --image /tmp/haiku.img uname +Haiku + +./haiku.x86_64 --verbose --image /tmp/haiku.img "gcc -v" +Using built-in specs. +COLLECT_GCC=gcc +COLLECT_LTO_WRAPPER=/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/lto-wrapper +Target: x86_64-unknown-haiku +Configured with: /sources/gcc-8.3.0/configure --build=x86_64-unknown-haiku --prefix=/packages/gcc-8.3.0_2019_05_24-7/.self/develop/tools --libexecdir=/packages/gcc-8.3.0_2019_05_24-7/.self/develop/tools/lib --mandir=/packages/gcc-8.3.0_2019_05_24-7/.self/documentation/man --docdir=/packages/gcc-8.3.0_2019_05_24-7/.self/documentation/packages/gcc --enable-threads=posix --disable-nls --enable-shared --with-gnu-ld --with-gnu-as --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran,objc --enable-lto --enable-frame-pointer --with-pkgversion=2019_05_24 --enable-__cxa-atexit --with-system-zlib --enable-checking=release --with-bug-url=http://dev.haiku-os.org/ --with-default-libstdcxx-abi=gcc4-compatible --enable-libssp --disable-multilib +Thread model: posix +gcc version 8.3.0 (2019_05_24) + + +and away we go.. + +./haiku.x86_64 --image /tmp/haiku.img --build-qemu /home/kallisti5/Code/qemu +Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' +Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 'slirp' +Submodule 'meson' (https://github.com/mesonbuild/meson/) registered for path 'meson' +Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) registered for path 'ui/keycodemapdb' +Submodule 'tests/fp/berkeley-softfloat-3' (https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 'tests/fp/berkeley-softfloat-3' +Submodule 'tests/fp/berkeley-testfloat-3' (https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 'tests/fp/berkeley-testfloat-3' +cross containers no + +NOTE: guest cross-compilers enabled: cc +The Meson build system +Version: 0.55.1 +Source dir: /boot/system/cache/tmp/qemu-test.oCwd7u/src +Build dir: /boot/system/cache/tmp/qemu-test.oCwd7u/build +Build type: native build +Project name: qemu +Project version: 5.1.50 +C compiler for the host machine: cc (gcc 8.3.0 "cc (2019_05_24) 8.3.0") +C linker for the host machine: cc ld.bfd 2.31.1 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or forwards compatibility and might not exist in future releases. +Program sh found: YES +Program python3 found: YES (/boot/system/bin/python3) +C++ compiler for the host machine: c++ (gcc 8.3.0 "c++ (2019_05_24) 8.3.0") +C++ linker for the host machine: c++ ld.bfd 2.31.1 +Configuring ninjatool using configuration +Library m found: YES +Library util found: NO +Library posix_error_mapper found: YES +Library network found: YES +Library bsd found: YES +Found pkg-config: /boot/system/bin/pkg-config (0.29.2) +Run-time dependency pixman-1 found: YES 0.38.4 +Library aio found: NO +Run-time dependency zlib found: YES 1.2.11 +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Library rt found: NO +Run-time dependency sdl2 found: YES 2.0.10 +Run-time dependency sdl2_image found: NO (tried pkgconfig) +Run-time dependency libpng found: YES 1.6.37 +Has header "jpeglib.h" : YES +. +. +/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp/src/tftp.c:113:50: error: 'O_BINARY' undeclared (first use in this function); did you mean 'L_INCR'? + spt->fd = open(spt->filename, O_RDONLY | O_BINARY); + ^~~~~~~~ + L_INCR +/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp/src/tftp.c:113:50: note: each undeclared identifier is reported only once for each function it appears in +Makefile:45: recipe for target '/boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/tftp.o' failed +make[1]: *** [/boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/tftp.o] Error 1 +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: *** Waiting for unfinished jobs.... +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/util.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/ip6_output.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/state.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/misc.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/bootp.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: *** wait: No child process. Stop. +Makefile:178: recipe for target 'slirp/all' failed +make: *** [slirp/all] Error 2 +make: *** Waiting for unfinished jobs.... +python3 -B /tmp/qemu-test.oCwd7u/src/meson/meson.py introspect --tests | python3 -B scripts/mtest2make.py > Makefile.mtest +./ninjatool -t ninja2make --omit clean dist uninstall cscope TAGS ctags < build.ninja > Makefile.ninja + + + +It looks like we have a few out-of-tree patches to fix that: + +https://github.com/haikuports/haikuports/blob/master/app-emulation/qemu/patches/qemu-2.11.1.patchset + +A patch for this work has been posted to the qemu-dev ML. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9fc33bf4e1d694225 +... the test suite is still failing, but at least we can compile test Haiku now. Thanks! + diff --git a/results/classifier/105/KVM/1723731 b/results/classifier/105/KVM/1723731 new file mode 100644 index 00000000..eb75f9aa --- /dev/null +++ b/results/classifier/105/KVM/1723731 @@ -0,0 +1,41 @@ +KVM: 0.655 +other: 0.633 +vnc: 0.596 +mistranslation: 0.587 +boot: 0.578 +instruction: 0.574 +device: 0.560 +network: 0.540 +socket: 0.531 +graphic: 0.515 +assembly: 0.515 +semantic: 0.502 + +Qemu turns to black screen while starting to copy installation files of Windows 7 + +Distribution: Arch Linux, Kernel: linux-4.13.5, Qemu: 2.10.1, OVMF: git (built 06.10.17). +Steps to reproduce: create Qemu VM with such config: + +QEMU_VM_NAME=$(basename $(dirname "$0")) #Qemu virtual machine name (taken from working directory) +QEMU_WORKING_DIR="$(dirname "$0")" #Qemu current working directory +DIF=12 #set 2-digit number here +QEMU_MONITOR_PORT=370${DIF} #Qemu monitor port +QEMU_SERIAL_PORT=371${DIF} #Qemu serial port +QEMU_PARALLEL_PORT=372${DIF} #Qemu parallel port + + +qemu-system-x86_64 -daemonize -display gtk -boot menu=on -monitor telnet:127.0.0.1:${QEMU_MONITOR_PORT},server,nowait -serial telnet:127.0.0.1:${QEMU_SERIAL_PORT},server,nowait -uuid fafafafa-1234-bcbc-5678-11112222ff${DIF} -name ${QEMU_VM_NAME},process=QEMU-${QEMU_VM_NAME} -parallel none -net none -nodefconfig -nodefaults -no-user-config -rtc base=localtime,clock=vm,driftfix=slew -realtime mlock=off -machine type=q35,accel=kvm,usb=off,dump-guest-core=off -smp 2,sockets=1,cores=2,threads=1 -object iothread,id=iothread1 -object iothread,id=iothread2 -cpu Penryn,kvm=off,check,vendor=GenuineIntel,+vmx -m 2G -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,addr=0x1b.0x0 -global qxl-vga.revision=4 -device ich9-intel-hda,addr=0x11.0x0,id=sound0 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device ich9-usb-ehci1,id=ehci1,addr=0x12.0x7 -device ich9-usb-uhci1,id=uhci1,masterbus=ehci1.0,firstport=0,multifunction=on,addr=0x12.0x0 -device ich9-usb-uhci2,id=uhci2,masterbus=ehci1.0,firstport=2,addr=0x12.0x1 -device ich9-usb-uhci3,id=uhci3,masterbus=ehci1.0,firstport=4,addr=0x12.0x2 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -drive file="${QEMU_WORKING_DIR}"/${QEMU_VM_NAME}.qcow2,if=none,media=disk,id=drive-sata0-0-0,format=qcow2 -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -drive if=none,media=cdrom,readonly=on,id=drive-sata0-0-1 -device usb-tablet,id=tbl0,bus=ehci1.0,port=2,usb_version=2,serial=1123,display=tbl0 +-device usb-kbd,id=kbd0,bus=ehci1.0,port=1,usb_version=1,serial=1122,display=kbd0 + +After that connect to Qemu console, insert Windows 7 installation media and start installation. You can successfully choose language, keyboard layout and partition your harddrive but after 2-3 seconds after beginning of copying installation files the graphical console screen turns to black and 1 CPU core on the host raises to 100% permanently and nothing happens. But if you installed Windows 7 before - there is no problems with VM. Tested on GTK, SDL types of screen. + +Qemu was installed from official repo and also I tried with built by myself version. Other OSes: Windows 8, 8.1, 10, Arch Linux, Debian, FreeBSD installed successfully. + +When you try to install Windows 7 in BIOS mode - you can pass all the installations steps, but after first reboot after installing guest agent, qxl and virtio-net drivers - OS freezes on Windows logo. + +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/105/KVM/1723927 b/results/classifier/105/KVM/1723927 new file mode 100644 index 00000000..da47818a --- /dev/null +++ b/results/classifier/105/KVM/1723927 @@ -0,0 +1,118 @@ +KVM: 0.761 +instruction: 0.743 +boot: 0.741 +other: 0.716 +assembly: 0.702 +graphic: 0.690 +device: 0.686 +network: 0.680 +semantic: 0.670 +mistranslation: 0.654 +vnc: 0.643 +socket: 0.634 + +Linux or windows guest boot failed by uefi on CPU of Intel Xeon X5675 + +Hi, + +I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and start process stop on +"TianoCore" image by looking at VNCviewer. + +VM using the command:(redhat7.0) +/usr/bin/kvm -name guest=ytest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/run/lib/libvirt/qemu/domain-40-ytest/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,system=windows,dump-guest-core=off -bios /usr/share/qemu-kvm/OVMF_CODE.fd -m size=8388608k,slots=10,maxmem=34359738368k -realtime mlock=off -smp 1,maxcpus=24,sockets=24,cores=1,threads=1 -numa node,nodeid=0,cpus=0-23,mem=8192 -uuid 8cf40bd6-258a-4550-ba4e-b38230547a11 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -chardev socket,id=charmonitor_cas,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock.cas,server,nowait -mon chardev=charmonitor_cas,id=monitor_cas,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x3 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x4 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device usb-hub,id=hub0,bus=usb.0,port=1 -drive file=/vms/hw235/ytest,format=qcow2,if=none,id=drive-virtio-disk0,cache=directsync,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,pci_hotpluggable=on,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-fdc0-0-0,readonly=on -global isa-fdc.driveA=drive-fdc0-0-0 -global isa-fdc.bootindexA=2 -netdev tap,fd=48,id=hostnet0,vhost=on,vhostfd=50 -device virtio-net-pci,pci_hotpluggable=on,netdev=hostnet0,id=net0,mac=0c:da:41:1d:67:6f,bus=pci.0,addr=0x5,bootindex=4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/ytest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 0.0.0.0:9 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on + +qemu version: 2.7.1 +edk2 version: git://git.code.sf.net/p/tianocore/edk2.git, commit: cc0b456a05f8dd1ebfb9be485465be37e96999e7 +server: ProLiant BL460c G7, CPU: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz + +Another, last version of edk2(compiled by myself) start guest is failed, too. But r15214 of edk2 start guest is ok(Download from http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip) + +Thanks in Advance + +On 10/16/17 13:26, chan wrote: +> Public bug reported: +> +> Hi, +> +> I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and start process stop on +> "TianoCore" image by looking at VNCviewer. +> +> VM using the command:(redhat7.0) +> /usr/bin/kvm -name guest=ytest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/run/lib/libvirt/qemu/domain-40-ytest/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,system=windows,dump-guest-core=off -bios /usr/share/qemu-kvm/OVMF_CODE.fd -m size=8388608k,slots=10,maxmem=34359738368k -realtime mlock=off -smp 1,maxcpus=24,sockets=24,cores=1,threads=1 -numa node,nodeid=0,cpus=0-23,mem=8192 -uuid 8cf40bd6-258a-4550-ba4e-b38230547a11 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -chardev socket,id=charmonitor_cas,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock.cas,server,nowait -mon chardev=charmonitor_cas,id=monitor_cas,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x3 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x4 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device usb-hub,id=hub0,bus=usb.0,port=1 -drive file=/vms/hw235/ytest,format=qcow2,if=none,id=drive-virtio-disk0,cache=directsync,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,pci_hotpluggable=on,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-fdc0-0-0,readonly=on -global isa-fdc.driveA=drive-fdc0-0-0 -global isa-fdc.bootindexA=2 -netdev tap,fd=48,id=hostnet0,vhost=on,vhostfd=50 -device virtio-net-pci,pci_hotpluggable=on,netdev=hostnet0,id=net0,mac=0c:da:41:1d:67:6f,bus=pci.0,addr=0x5,bootindex=4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/ytest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 0.0.0.0:9 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on +> +> qemu version: 2.7.1 +> edk2 version: git://git.code.sf.net/p/tianocore/edk2.git, commit: cc0b456a05f8dd1ebfb9be485465be37e96999e7 +> server: ProLiant BL460c G7, CPU: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> +> Another, last version of edk2(compiled by myself) start guest is failed, +> too. But r15214 of edk2 start guest is ok(Download from +> http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip) +> +> Thanks in Advance +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +Your command line is broken; + + -bios /usr/share/qemu-kvm/OVMF_CODE.fd + +has never been a correct option to boot OVMF. + +Your cmdline seems to have been generated by libvirt; make sure your domain XML says + +<domain type='kvm'> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu-kvm/OVMF_CODE.fd</loader> + </os> +</domain> + +If your libvirt daemon is set up correctly, then libvirt will generate the <nvram> element automatically for the above. (See the "nvram" stanza in "/etc/libvirt/qemu.conf". If you modify that, don't forget to restart libvirt.) + + +Also, you can capture the OVMF debug log with + +<domain type='kvm' + xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <------- don't forget to add this too + <qemu:commandline> + <qemu:arg value='-global'/> + <qemu:arg value='isa-debugcon.iobase=0x402'/> + <qemu:arg value='-debugcon'/> + <qemu:arg value='file:/tmp/GUEST_NAME.log'/> + </qemu:commandline> +</domain> + +Thanks, +Laszlo + + +Ersek, thank you very much! + +I set up correctly in "/etc/libvirt/qemu.conf", so command +-bios /usr/share/qemu-kvm/OVMF_CODE.fd +also boot UEFI guest. + +Current, my question only in the platform in server of ProLiant BL460c G7, +the same ovmf firmware. + +How can capture the OVMF debug log? +I use your advise, open ovmf debug in guest xml: +<qemu:commandline> + <qemu:arg value='-global'/> + <qemu:arg value='isa-debugcon.iobase=0x402'/> + <qemu:arg value='-debugcon'/> + <qemu:arg value='file:/tmp/GUEST_NAME.log'/> + </qemu:commandline> +but nothing output in /tmp/GUEST_NAME.log. +Another, I used debug version ovmf. + +I success to capture the OVMF debug log. + +"-bios /usr/share/qemu-kvm/OVMF_CODE.fd" is *never* a correct option to boot OVMF. + +Closing due to almost 3 years of inactivity. + diff --git a/results/classifier/105/KVM/1726 b/results/classifier/105/KVM/1726 new file mode 100644 index 00000000..2d4f0276 --- /dev/null +++ b/results/classifier/105/KVM/1726 @@ -0,0 +1,110 @@ +KVM: 0.789 +other: 0.763 +instruction: 0.741 +device: 0.736 +mistranslation: 0.714 +boot: 0.684 +vnc: 0.681 +assembly: 0.636 +graphic: 0.623 +semantic: 0.618 +socket: 0.580 +network: 0.502 + +qemu-system-ppc64 option -smp 2 broken with commit 20b6643324a79860dcdfe811ffe4a79942bca21e +Description of problem: +I was trying to boot rhel9 image with upstream qemu-system-ppc64 -smp 2 option and observed a segfault (qemu crash). +After doing a git bisect, I found the first bad commit which introduced this issue is below: +``` +[qemu]# git bisect good +20b6643324a79860dcdfe811ffe4a79942bca21e is the first bad commit +commit 20b6643324a79860dcdfe811ffe4a79942bca21e +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Mon Dec 5 17:45:02 2022 -0600 + + tcg/ppc: Reorg goto_tb implementation + + The old ppc64 implementation replaces 2 or 4 insns, which leaves a race + condition in which a thread could be stopped at a PC in the middle of + the sequence, and when restarted does not see the complete address + computation and branches to nowhere. + + The new implemetation replaces only one insn, swapping between + + b <dest> + and + mtctr r31 + + falling through to a general-case indirect branch. + + Reviewed-by: Alex Bennée <alex.bennee@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + + tcg/ppc/tcg-target.c.inc | 152 +++++++++++++---------------------------------- + tcg/ppc/tcg-target.h | 3 +- + 2 files changed, 41 insertions(+), 114 deletions(-) +[qemu]# +``` +Steps to reproduce: +1. Run the qemu command line mentioned +2. Wait for the qemu to crash. +Additional information: +git bisect log: +``` +[root@ltcden6-lp2 qemu]# git bisect log +git bisect start +# status: waiting for both good and bad commits +# bad: [b455ce4c2f300c8ba47cba7232dd03261368a4cb] Merge tag 'q800-for-8.1-pull-request' of https://github.com/vivier/qemu-m68k into staging +git bisect bad b455ce4c2f300c8ba47cba7232dd03261368a4cb +# status: waiting for good commit(s), bad commit known +# good: [b247dba067bf2808de6395ff09ff0cb220ed7c95] tests/avocado: add explicit timeout for ppc64le TCG tests +git bisect good b247dba067bf2808de6395ff09ff0cb220ed7c95 +# bad: [3db629f03e8caf39526cd0415dac16a6a6484107] Merge tag 'pull-request-2023-02-27' of https://gitlab.com/thuth/qemu into staging +git bisect bad 3db629f03e8caf39526cd0415dac16a6a6484107 +# good: [777fa06376ce0249c76d0d852e8f7ed103a63864] Merge tag 'pull-loongarch-20221202' of https://gitlab.com/gaosong/qemu into staging +git bisect good 777fa06376ce0249c76d0d852e8f7ed103a63864 +# bad: [c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8] target/riscv/cpu: set cpu->cfg in register_cpu_props() +git bisect bad c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8 +# good: [bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0] hw/intc: sifive_plic: Fix the pending register range check +git bisect good bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0 +# good: [aa96ab7c9df59c615ca82b49c9062819e0a1c287] Merge tag 'pull-request-2023-01-09' of https://gitlab.com/thuth/qemu into staging +git bisect good aa96ab7c9df59c615ca82b49c9062819e0a1c287 +# good: [a8d6abe1292e1db1ad9be5b2b124b9c01bcda094] Merge tag 'mips-20230113' of https://github.com/philmd/qemu into staging +git bisect good a8d6abe1292e1db1ad9be5b2b124b9c01bcda094 +# bad: [ef4f031fab7b070816454949a1b6b6c7aa3cf503] Merge tag 'pull-tcg-20230117' of https://gitlab.com/rth7680/qemu into staging +git bisect bad ef4f031fab7b070816454949a1b6b6c7aa3cf503 +# good: [0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85] tcg: Change tb_target_set_jmp_target arguments +git bisect good 0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85 +# good: [701ed34833f53880ba38bde09b0846d01fc16d66] Merge tag 'pull-request-2023-01-18' of https://gitlab.com/thuth/qemu into staging +git bisect good 701ed34833f53880ba38bde09b0846d01fc16d66 +# bad: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation +git bisect bad 20b6643324a79860dcdfe811ffe4a79942bca21e +# good: [90c0fee3a28b25d23081b3c435762cadde813ec4] tcg: Always define tb_target_set_jmp_target +git bisect good 90c0fee3a28b25d23081b3c435762cadde813ec4 +# good: [d59d83a1c38869b1e1a4f957eb939aaa8a342721] tcg/aarch64: Reorg goto_tb implementation +git bisect good d59d83a1c38869b1e1a4f957eb939aaa8a342721 +# first bad commit: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation +``` + +gdb backtrace output: + +``` +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00007fff4becfa8c in ?? () +[Current thread is 1 (Thread 0x7fff9e80e780 (LWP 31456))] +(gdb) bt +#0 0x00007fff4becfa8c in () +#1 0x00007fff5682d044 in code_gen_buffer () +#2 0x000000013e3224ec in cpu_tb_exec (cpu=cpu@entry=0x16144fb70, itb=itb@entry=0x7fff5682cf00 <code_gen_buffer+111332932>, tb_exit=tb_exit@entry=0x7fff9e80d7f0) at ../accel/tcg/cpu-exec.c:438 +#3 0x000000013e322ad4 in cpu_loop_exec_tb (tb_exit=0x7fff9e80d7f0, last_tb=<synthetic pointer>, pc=13835058055286981664, tb=0x7fff5682cf00 <code_gen_buffer+111332932>, cpu=<optimized out>) + at ../accel/tcg/cpu-exec.c:871 +#4 cpu_exec_loop (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:981 +#5 0x000000013e3234e8 in cpu_exec_setjmp (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:1012 +#6 0x000000013e323e64 in cpu_exec (cpu=0x16144fb70) at ../accel/tcg/cpu-exec.c:1038 +#7 0x000000013e35bba0 in tcg_cpus_exec (cpu=0x16144fb70) at ../accel/tcg/tcg-accel-ops.c:69 +#8 0x000000013e35bd90 in mttcg_cpu_thread_fn (arg=0x16144fb70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#9 0x000000013e57193c in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:505 +#10 0x00007fffa12aa0f0 in start_thread (arg=0x7fff9e80e780) at pthread_create.c:443 +#11 0x00007fffa1352ec8 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107 +``` +For any further additional information contact me at : anushree.mathur@linux.vnet.ibm.com diff --git a/results/classifier/105/KVM/1728615 b/results/classifier/105/KVM/1728615 new file mode 100644 index 00000000..fd219c83 --- /dev/null +++ b/results/classifier/105/KVM/1728615 @@ -0,0 +1,538 @@ +KVM: 0.810 +vnc: 0.784 +other: 0.757 +mistranslation: 0.709 +graphic: 0.662 +boot: 0.618 +instruction: 0.588 +device: 0.575 +assembly: 0.534 +semantic: 0.530 +socket: 0.480 +network: 0.468 + +qemu-io crashes with SIGABRT and Assertion `c->entries[i].offset != 0' failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named backing_img.file and test.img to a directory +2. And customize the following command to point to the above directory and run the same. +/usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" + +3.Output of the above command. +qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +Aborted (core dumped) + +from gdb: +(gdb) bt +#0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +#1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +#2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +#5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +#6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 +#7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +#8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) + at block/qcow2-cluster.c:1221 +#9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1324 +#10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1511 +#11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +#12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +#13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) + at block/io.c:1440 +#14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +#15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +#17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +#18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +#19 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 + i = 0 + __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +#5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 + s = 0x2e893210 + refcount_table_index = 0 + ret = 0 + new_block = 0 + blocks_used = 72057594818669408 + meta_offset = 1572863 +#6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 + block_index = 268870408 + refcount = 780741808 + cluster_index = 2 + table_index = 0 + s = 0x2e893210 + start = 1048576 + last = 1048576 + cluster_offset = 1048576 + refcount_block = 0x3fff81200000 + old_table_index = -1 + ret = 16383 +#7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 + s = 0x2e893210 + cluster_index = 3 + refcount = 0 + i = 1 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +#8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) + at block/qcow2-cluster.c:1221 + ret = 780743184 + s = 0x2e893210 +#9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1324 + s = 0x2e893210 + l2_index = 4 + l2_table = 0x0 + entry = 0 + nb_clusters = 1 + ret = 0 +---Type <return> to continue, or q <return> to quit--- + keep_old_clusters = false + alloc_cluster_offset = 1048576 + __PRETTY_FUNCTION__ = "handle_alloc" + requested_bytes = 17960562528 + avail_bytes = -2133853344 + nb_bytes = 16383 + old_m = 0x100000000 +#10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1511 + s = 0x2e893210 + start = 2097152 + remaining = 962560 + cluster_offset = 1048576 + cur_bytes = 962560 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 + s = 0x2e893210 + offset_in_cluster = 0 + ret = 0 + cur_bytes = 1486848 + cluster_offset = 524288 + hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} + bytes_done = 220672 + cluster_data = 0x0 + l2meta = 0x0 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 780706080 + nb_sectors = 3069122264 + ret = -203160320 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) + at block/io.c:1440 + bs = 0x2e886f60 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 + end_sector = 5976 + bytes_remaining = 1707520 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x2e886f60 + req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, + overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 +---Type <return> to continue, or q <return> to quit--- + tail_buf = 0x0 + local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x2e886f60 +#16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 + rwco = 0x3fffc85f0c08 +#17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x2e895a90, i = {780753552, 0}} + self = 0x2e895a90 + co = 0x2e895a90 +#18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#19 0x0000000000000000 in ?? () +No symbol table info available. + +Will attach the 'image_fuzzer' images. + + + +On Wed 01 Nov 2017 07:13:08 AM CET, Thomas Huth wrote: +> On 30.10.2017 15:43, R.Nageswara Sastry wrote: +>> Public bug reported: +>> +>> git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +>> This is on ppc64le architecture. +>> +>> Re-production steps: +>> +>> 1. Copy the attached files named backing_img.file and test.img to a directory +>> 2. And customize the following command to point to the above directory and run the same. +>> /usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" +>> +>> 3.Output of the above command. +>> qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +>> Aborted (core dumped) +>> +>> from gdb: +>> (gdb) bt +>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>> at block/qcow2-refcount.c:834 +>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>> at block/qcow2-cluster.c:1221 +>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1324 +>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1511 +>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>> at block/io.c:1440 +>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>> #19 0x0000000000000000 in ?? () +>> (gdb) bt full +>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>> No symbol table info available. +>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>> No symbol table info available. +>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>> No symbol table info available. +>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>> No symbol table info available. +>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>> i = 0 +>> __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>> s = 0x2e893210 +>> refcount_table_index = 0 +>> ret = 0 +>> new_block = 0 +>> blocks_used = 72057594818669408 +>> meta_offset = 1572863 +>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>> at block/qcow2-refcount.c:834 +>> block_index = 268870408 +>> refcount = 780741808 +>> cluster_index = 2 +>> table_index = 0 +>> s = 0x2e893210 +>> start = 1048576 +>> last = 1048576 +>> cluster_offset = 1048576 +>> refcount_block = 0x3fff81200000 +>> old_table_index = -1 +>> ret = 16383 +>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>> s = 0x2e893210 +>> cluster_index = 3 +>> refcount = 0 +>> i = 1 +>> ret = 0 +>> __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>> at block/qcow2-cluster.c:1221 +>> ret = 780743184 +>> s = 0x2e893210 +>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1324 +>> s = 0x2e893210 +>> l2_index = 4 +>> l2_table = 0x0 +>> entry = 0 +>> nb_clusters = 1 +>> ret = 0 +>> ---Type <return> to continue, or q <return> to quit--- +>> keep_old_clusters = false +>> alloc_cluster_offset = 1048576 +>> __PRETTY_FUNCTION__ = "handle_alloc" +>> requested_bytes = 17960562528 +>> avail_bytes = -2133853344 +>> nb_bytes = 16383 +>> old_m = 0x100000000 +>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1511 +>> s = 0x2e893210 +>> start = 2097152 +>> remaining = 962560 +>> cluster_offset = 1048576 +>> cur_bytes = 962560 +>> ret = 0 +>> __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>> s = 0x2e893210 +>> offset_in_cluster = 0 +>> ret = 0 +>> cur_bytes = 1486848 +>> cluster_offset = 524288 +>> hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} +>> bytes_done = 220672 +>> cluster_data = 0x0 +>> l2meta = 0x0 +>> __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>> drv = 0x102036f0 <bdrv_qcow2> +>> sector_num = 780706080 +>> nb_sectors = 3069122264 +>> ret = -203160320 +>> __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>> at block/io.c:1440 +>> bs = 0x2e886f60 +>> drv = 0x102036f0 <bdrv_qcow2> +>> waited = false +>> ret = 0 +>> end_sector = 5976 +>> bytes_remaining = 1707520 +>> max_transfer = 2147483647 +>> __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>> bs = 0x2e886f60 +>> req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, +>> overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, +>> sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} +>> align = 1 +>> head_buf = 0x0 +>> ---Type <return> to continue, or q <return> to quit--- +>> tail_buf = 0x0 +>> local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} +>> use_local_qiov = false +>> ret = 0 +>> __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>> ret = 0 +>> bs = 0x2e886f60 +>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>> rwco = 0x3fffc85f0c08 +>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>> arg = {p = 0x2e895a90, i = {780753552, 0}} +>> self = 0x2e895a90 +>> co = 0x2e895a90 +>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>> No symbol table info available. +>> #19 0x0000000000000000 in ?? () +>> No symbol table info available. +> +> Can you also reproduce this on x86, or is it specific to ppc64? + +I can actually reproduce it myself, I'll take a look. + +Berto + + +On Wed 01 Nov 2017 09:55:21 AM CET, Alberto Garcia wrote: +> On Wed 01 Nov 2017 07:13:08 AM CET, Thomas Huth wrote: +>> On 30.10.2017 15:43, R.Nageswara Sastry wrote: +>>> Public bug reported: +>>> +>>> git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +>>> This is on ppc64le architecture. +>>> +>>> Re-production steps: +>>> +>>> 1. Copy the attached files named backing_img.file and test.img to a directory +>>> 2. And customize the following command to point to the above directory and run the same. +>>> /usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" +>>> +>>> 3.Output of the above command. +>>> qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +>>> Aborted (core dumped) +>>> +>>> from gdb: +>>> (gdb) bt +>>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>>> at block/qcow2-refcount.c:834 +>>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>>> at block/qcow2-cluster.c:1221 +>>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1324 +>>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1511 +>>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>>> at block/io.c:1440 +>>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>>> #19 0x0000000000000000 in ?? () +>>> (gdb) bt full +>>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>>> i = 0 +>>> __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +>>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>>> s = 0x2e893210 +>>> refcount_table_index = 0 +>>> ret = 0 +>>> new_block = 0 +>>> blocks_used = 72057594818669408 +>>> meta_offset = 1572863 +>>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>>> at block/qcow2-refcount.c:834 +>>> block_index = 268870408 +>>> refcount = 780741808 +>>> cluster_index = 2 +>>> table_index = 0 +>>> s = 0x2e893210 +>>> start = 1048576 +>>> last = 1048576 +>>> cluster_offset = 1048576 +>>> refcount_block = 0x3fff81200000 +>>> old_table_index = -1 +>>> ret = 16383 +>>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>>> s = 0x2e893210 +>>> cluster_index = 3 +>>> refcount = 0 +>>> i = 1 +>>> ret = 0 +>>> __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +>>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>>> at block/qcow2-cluster.c:1221 +>>> ret = 780743184 +>>> s = 0x2e893210 +>>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1324 +>>> s = 0x2e893210 +>>> l2_index = 4 +>>> l2_table = 0x0 +>>> entry = 0 +>>> nb_clusters = 1 +>>> ret = 0 +>>> ---Type <return> to continue, or q <return> to quit--- +>>> keep_old_clusters = false +>>> alloc_cluster_offset = 1048576 +>>> __PRETTY_FUNCTION__ = "handle_alloc" +>>> requested_bytes = 17960562528 +>>> avail_bytes = -2133853344 +>>> nb_bytes = 16383 +>>> old_m = 0x100000000 +>>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1511 +>>> s = 0x2e893210 +>>> start = 2097152 +>>> remaining = 962560 +>>> cluster_offset = 1048576 +>>> cur_bytes = 962560 +>>> ret = 0 +>>> __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +>>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>>> s = 0x2e893210 +>>> offset_in_cluster = 0 +>>> ret = 0 +>>> cur_bytes = 1486848 +>>> cluster_offset = 524288 +>>> hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} +>>> bytes_done = 220672 +>>> cluster_data = 0x0 +>>> l2meta = 0x0 +>>> __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +>>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>>> drv = 0x102036f0 <bdrv_qcow2> +>>> sector_num = 780706080 +>>> nb_sectors = 3069122264 +>>> ret = -203160320 +>>> __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +>>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>>> at block/io.c:1440 +>>> bs = 0x2e886f60 +>>> drv = 0x102036f0 <bdrv_qcow2> +>>> waited = false +>>> ret = 0 +>>> end_sector = 5976 +>>> bytes_remaining = 1707520 +>>> max_transfer = 2147483647 +>>> __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +>>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>>> bs = 0x2e886f60 +>>> req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, +>>> overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, +>>> sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} +>>> align = 1 +>>> head_buf = 0x0 +>>> ---Type <return> to continue, or q <return> to quit--- +>>> tail_buf = 0x0 +>>> local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} +>>> use_local_qiov = false +>>> ret = 0 +>>> __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +>>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>>> ret = 0 +>>> bs = 0x2e886f60 +>>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>>> rwco = 0x3fffc85f0c08 +>>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>>> arg = {p = 0x2e895a90, i = {780753552, 0}} +>>> self = 0x2e895a90 +>>> co = 0x2e895a90 +>>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #19 0x0000000000000000 in ?? () +>>> No symbol table info available. +>> +>> Can you also reproduce this on x86, or is it specific to ppc64? + +I'm working on a fix, I'll send the patch later today. + +Berto + + +The attached image is corrupted and QEMU doesn't handle it correctly. + +Here are the fixes for this and other related problems: + + https://lists.gnu.org/archive/html/qemu-block/2017-11/msg00010.html + + +Fix has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6bf45d59f98c898b7d79 + diff --git a/results/classifier/105/KVM/1728657 b/results/classifier/105/KVM/1728657 new file mode 100644 index 00000000..ae454afe --- /dev/null +++ b/results/classifier/105/KVM/1728657 @@ -0,0 +1,134 @@ +KVM: 0.252 +other: 0.233 +vnc: 0.182 +device: 0.174 +instruction: 0.153 +graphic: 0.147 +mistranslation: 0.138 +assembly: 0.133 +semantic: 0.126 +boot: 0.121 +socket: 0.109 +network: 0.098 + +qemu-io: block/qcow2-cluster.c:1109: handle_copied: Assertion failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "write 4105728 2791936" + +from gdb: +(gdb) bt +#0 0x00003fffb17eeff0 in raise () from /lib64/libc.so.6 +#1 0x00003fffb17f136c in abort () from /lib64/libc.so.6 +#2 0x00003fffb17e4c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fffb17e4d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000100631fc in handle_copied (bs=0x42ba9ad0, guest_offset=4210688, host_offset=0x3fffaf4bfab0, bytes=0x3fffaf4bfab8, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1108 +#5 0x0000000010064118 in qcow2_alloc_cluster_offset (bs=0x42ba9ad0, offset=4194304, bytes=0x3fffaf4bfb4c, host_offset=0x3fffaf4bfb58, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1498 +#6 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x42ba9ad0, offset=4194304, bytes=2703360, qiov=0x3fffc7cc9ee0, flags=0) at block/qcow2.c:1919 +#7 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x42ba9ad0, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=16) at block/io.c:898 +#8 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x42bb8250, req=0x3fffaf4bfdd8, offset=4105728, bytes=2791936, align=1, qiov=0x3fffc7cc9ee0, flags=16) + at block/io.c:1440 +#9 0x00000000100ac4ac in bdrv_co_pwritev (child=0x42bb8250, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/io.c:1691 +#10 0x000000001008da0c in blk_co_pwritev (blk=0x42b99410, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#11 0x000000001008db68 in blk_write_entry (opaque=0x3fffc7cc9ef8) at block/block-backend.c:1110 +#12 0x00000000101aa444 in coroutine_trampoline (i0=1119572144, i1=0) at util/coroutine-ucontext.c:79 +#13 0x00003fffb1802b9c in makecontext () from /lib64/libc.so.6 +#14 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fffb17eeff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fffb17f136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fffb17e4c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fffb17e4d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x00000000100631fc in handle_copied (bs=0x42ba9ad0, guest_offset=4210688, host_offset=0x3fffaf4bfab0, bytes=0x3fffaf4bfab8, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1108 + s = 0x42bb5d80 + l2_index = 0 + cluster_offset = 4210688 + l2_table = 0x0 + nb_clusters = 1119575424 + keep_clusters = 0 + ret = 0 + __PRETTY_FUNCTION__ = "handle_copied" +#5 0x0000000010064118 in qcow2_alloc_cluster_offset (bs=0x42ba9ad0, offset=4194304, bytes=0x3fffaf4bfb4c, host_offset=0x3fffaf4bfb58, m=0x3fffaf4bfb60) + at block/qcow2-cluster.c:1498 + s = 0x42bb5d80 + start = 4210688 + remaining = 2686976 + cluster_offset = 4294983168 + cur_bytes = 2686976 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#6 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x42ba9ad0, offset=4194304, bytes=2703360, qiov=0x3fffc7cc9ee0, flags=0) at block/qcow2.c:1919 + s = 0x42bb5d80 + offset_in_cluster = 0 + ret = 0 + cur_bytes = 2703360 + cluster_offset = 4294950912 + hd_qiov = {iov = 0x42b74fb0, niov = 1, nalloc = 1, size = 16384} + bytes_done = 88576 + cluster_data = 0x0 + l2meta = 0x42bb5d20 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#7 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x42ba9ad0, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 1119538320 + nb_sectors = 2841469356 + ret = 2116577536 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#8 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x42bb8250, req=0x3fffaf4bfdd8, offset=4105728, bytes=2791936, align=1, qiov=0x3fffc7cc9ee0, flags=16) + at block/io.c:1440 + bs = 0x42ba9ad0 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 +---Type <return> to continue, or q <return> to quit--- + end_sector = 13472 + bytes_remaining = 2791936 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#9 0x00000000100ac4ac in bdrv_co_pwritev (child=0x42bb8250, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x42ba9ad0 + req = {bs = 0x42ba9ad0, offset = 4105728, bytes = 2791936, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 4105728, + overlap_bytes = 2791936, list = {le_next = 0x0, le_prev = 0x42bacd48}, co = 0x42bb50b0, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fffaf4bfe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x3fffaf4bfdb0, niov = -1353974288, nalloc = 16383, size = 4105728} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#10 0x000000001008da0c in blk_co_pwritev (blk=0x42b99410, offset=4105728, bytes=2791936, qiov=0x3fffc7cc9ee0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x42ba9ad0 +#11 0x000000001008db68 in blk_write_entry (opaque=0x3fffc7cc9ef8) at block/block-backend.c:1110 + rwco = 0x3fffc7cc9ef8 +#12 0x00000000101aa444 in coroutine_trampoline (i0=1119572144, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x42bb50b0, i = {1119572144, 0}} + self = 0x42bb50b0 + co = 0x42bb50b0 +#13 0x00003fffb1802b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#14 0x0000000000000000 in ?? () +No symbol table info available. + +will attach images_fuzzer image. + + + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=93bbaf03ff7fd490e82 + diff --git a/results/classifier/105/KVM/1731957 b/results/classifier/105/KVM/1731957 new file mode 100644 index 00000000..3993e166 --- /dev/null +++ b/results/classifier/105/KVM/1731957 @@ -0,0 +1,56 @@ +KVM: 0.705 +mistranslation: 0.699 +instruction: 0.677 +vnc: 0.675 +other: 0.672 +network: 0.668 +socket: 0.661 +boot: 0.658 +assembly: 0.653 +graphic: 0.651 +device: 0.644 +semantic: 0.630 + +qemu-kvm exits with console permission problems + +# rpm -qa | grep qemu +qemu-img-ev-2.9.0-16.el7_4.8.1.x86_64 +qemu-kvm-ev-2.9.0-16.el7_4.8.1.x86_64 +ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch +libvirt-daemon-driver-qemu-3.2.0-14.el7_4.3.x86_64 +qemu-kvm-common-ev-2.9.0-16.el7_4.8.1.x86_64 + +qemu.conf: +stdio_handler = "file" + +libvirtd runs as root with '/usr/sbin/libvirtd --listen' + +we run openstack, it creates an instance like this: + +2017-11-13 15:17:14.143+0000: starting up libvirt version: 3.2.0, package: 14.el7_4.3 (Unknown, 2017-09-05-02:55:29, x86-ol7-builder +-02.us.oracle.com), qemu version: 2.9.0(qemu-kvm-ev-2.9.0-16.el7_4.8.1), hostname: compute6 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/root QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=instance-00000016,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-00000016/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,xsaveopt=on,abm=on,invpcid=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=de115ee2-a86f-432d-96fe-bec91b0a5748,uuid=48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-00000016/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot + strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/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=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:bf:f5:40,bus=pci.0,addr=0x3 -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83 +a2ffdf/console.log,logappend=off -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:1 -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 + +With older qemu like 2.5 or 2.6 console log belongs to qemu:qemu and the process starts successfully. +With 2.9 it fails and console.log is left root:root : + +2017-11-13 15:17:14.173+0000: 26010: debug : qemuProcessHook:2738 : Hook complete ret=0 +2017-11-13 15:17:14.173+0000: 26010: debug : virExec:699 : Done hook 0 +2017-11-13 15:17:14.173+0000: 26010: debug : virExec:736 : Setting child uid:gid to 42427:42427 with caps 0 +2017-11-13 15:17:14.173+0000: 26010: debug : virCommandHandshakeChild:435 : Notifying parent for handshake start on 29 +2017-11-13 15:17:14.173+0000: 26010: debug : virCommandHandshakeChild:443 : Waiting on parent for handshake complete on 30 +2017-11-13 15:17:14.192+0000: 26010: debug : virFileClose:110 : Closed fd 29 +2017-11-13 15:17:14.192+0000: 26010: debug : virFileClose:110 : Closed fd 30 +2017-11-13 15:17:14.192+0000: 26010: debug : virCommandHandshakeChild:463 : Handshake with parent is done +2017-11-13T15:17:14.232713Z qemu-kvm: -chardev pty,id=charserial0,logfile=/var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/console.log,logappend=off: Unable to open logfile /var/lib/nova/instances/48ea957f-6fbc-4b43-83c8-8c5e83a2ffdf/console.log: Permission denied +2017-11-13 15:17:14.321+0000: shutting down, reason=failed + +These might be helpful or related: +- https://bugzilla.redhat.com/show_bug.cgi?id=1499800 +- https://bugzilla.redhat.com/show_bug.cgi?id=1501957 + +Sounds like this is/was rather an issue with libvirt or openstack, but certainly not qemu. If the problem still persists, please report it to those projects first. Thanks! + diff --git a/results/classifier/105/KVM/1752026 b/results/classifier/105/KVM/1752026 new file mode 100644 index 00000000..bf5fc62d --- /dev/null +++ b/results/classifier/105/KVM/1752026 @@ -0,0 +1,1262 @@ +KVM: 0.732 +vnc: 0.730 +other: 0.718 +instruction: 0.712 +semantic: 0.691 +socket: 0.684 +boot: 0.670 +network: 0.663 +graphic: 0.652 +device: 0.633 +mistranslation: 0.633 +assembly: 0.583 + +Ubuntu18.04:POWER9:DD2.2 - Unable to start a KVM guest with default machine type(pseries-bionic) complaining "KVM implementation does not support Transactional Memory, try cap-htm=off" (kvm) + +== Comment: #0 - Satheesh Rajendran <email address hidden> - 2018-02-23 08:31:06 == +---Problem Description--- +libvirt unable to start a KVM guest complaining about cap-htm machine property to be off + +Host Env: +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 160 +On-line CPU(s) list: 0-159 +Thread(s) per core: 4 +Core(s) per socket: 20 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.2 (pvr 004e 1202) +Model name: POWER9 (raw), altivec supported +CPU max MHz: 3800.0000 +CPU min MHz: 2166.0000 +L1d cache: 32K +L1i cache: 32K +L2 cache: 512K +L3 cache: 10240K +NUMA node0 CPU(s): 0-79 +NUMA node8 CPU(s): 80-159 + +ii qemu-kvm 1:2.11+dfsg-1ubuntu2 ppc64el QEMU Full virtualization on x86 hardware + +ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +# lsmcode +Version of System Firmware : + Product Name : OpenPOWER Firmware + Product Version : open-power-SUPERMICRO-P9DSU-V1.03-20180205-imp + Product Extra : occ-577915f + Product Extra : skiboot-v5.9-240-g081882690163-pcbedce4 + Product Extra : petitboot-v1.6.6-p019c87e + Product Extra : sbe-095e608 + Product Extra : machine-xml-fb5f933 + Product Extra : hostboot-9bfb201 + Product Extra : linux-4.14.13-openpower1-p78d7eee + + + +Contact Information = <email address hidden> + +---uname output--- +4.15.0-10-generic + +Machine Type = power9 boston 2.2 (pvr 004e 1202) + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + 1. Boot a guest from libvirt with default pseries machine type or pseries-bionic + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'virt-tests-vm1' --machine pseries --memory=32768 --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:77:78:79 --noautoconsole +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +Starting install... +ERROR internal error: process exited while connecting to monitor: ,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///system start virt-tests-vm1 +otherwise, please restart your installation. + +2. Fails to boot.. + +Note: if we specify machine type as pseries=2.12 it boots fine like below + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'virt-tests-vm1' --machine pseries-2.12 --memory=32768 --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:77:78:79 --noautoconsole +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +qemu-cmd line: + +libvirt+ 4283 1 99 09:26 ? 00:00:38 qemu-system-ppc64 -enable-kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/master-key.aes -machine pseries-2.12,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 108ac2b5-e8b2-4399-a925-a707e8020871 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-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,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + + +Userspace tool common name: ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +The userspace tool has the following bit modes: both + +Userspace rpm: ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. + +== Comment: #1 - Satheesh Rajendran <email address hidden> - 2018-02-23 08:35:17 == +vm qemu log for failed and passed cases: + +Failed:(pseries-bionic) +2018-02-23 14:21:10.806+0000: starting up libvirt version: 4.0.0, package: 1ubuntu3 (Christian Ehrhardt <email address hidden> Mon, 19 Feb 2018 14:18:44 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu2), hostname: ltc-boston8.aus.stglabs.ibm.com +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-virt-tests-vm1/master-key.aes -machine pseries-bionic,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 36c37d3b-fb24-4350-94f9-3271b257f75c -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-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,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:10.909242Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +2018-02-23 14:21:18.857+0000: shutting down, reason=failed + + +Passed:(pseries-2.12) +2018-02-23 14:26:07.047+0000: starting up libvirt version: 4.0.0, package: 1ubuntu3 (Christian Ehrhardt <email address hidden> Mon, 19 Feb 2018 14:18:44 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu2), hostname: ltc-boston8.aus.stglabs.ibm.com +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/master-key.aes -machine pseries-2.12,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 108ac2b5-e8b2-4399-a925-a707e8020871 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-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,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:26:07.116991Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) + +Regards, +-Satheesh + +== Comment: #8 - VIPIN K. PARASHAR <email address hidden> - 2018-02-25 23:38:29 == +Starting install... +ERROR internal error: process exited while connecting to monitor: ,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///system start virt-tests-vm1 +otherwise, please restart your installation. + +As per above message, qemu is reporting TM to be not supported by KVM on this hardware +and thus recommending to turn off cap-htm. + +== Comment: #12 - Suraj Jitindar Singh <email address hidden> - 2018-02-26 23:35:02 == +I don't know what a pseries-bionic is, there is no reference to it upstream. + +What you are seeing is expected behaviour as far as I can tell. POWER9 currently does not support HTM for a guest and thus it must not be turned on, otherwise qemu will fail to start. + +HTM can be disabled from the qemu command line by setting cap-htm=off, as stated in the the error message. The pseries-2.12 machine type has htm disabled by default and thus with that machine type there is no requirement to set cap-htm=off on the command line to get qemu to start. + +So depending on what machine pseries-bionic is based on it will be required to disable htm on the command line (with cap-htm=off) if it is not disabled by default for the machine. + +== Comment: #13 - Satheesh Rajendran <email address hidden> - 2018-02-27 00:05:12 == +Had a chat with Suraj and here is the summary + +1. Currently Power9 DD2.2(host kernel) does not support HTM, so guest should be booted with cap-htm=off, looks like host kernel patch rework in progress--> Initial patch, https://www.spinics.net/lists/kvm-ppc/msg13378.html +2. Libvirt does not know about this cap-htm yet and currently it does not set any default values? +3. pseries-2.12 does have cap-htm=off by default but not the older machine types, so we see the guest is booting from libvirt with pseries-2.12 +4. Once 1 is fixed, we can boot cap-htm=on, I guess by that time pseries-2.12 to be changed to cap-htm=on bydefault. + +---> 3. Immediate fix can be Canonical defaults their machine type(pseries-bioic) to pseries-2.12... +---> Future 1 and 4 to be addressed, not sure about 2? + +Needs a mirror to Canonical to address this. + +Regards, +-Satheesh + +Hi, the long description in this bug is a little confusing. Some of the comments appear to suggest that the required support is not yet upstream. + +Could the reporter confirm whether there any current upstream patches that require backporting urgently (the bug is marked as critical)? + +Or whether further upstream work is required before backporting should begin. + +Thanks, Andy. + + +Hi, +Thanks Andrew - I agree in general. +The following is based on the assumption that the linked discussion (kernel change) is not upstream yet. +Any clarification on that will help thou. + +OTOH I want to start the discussion on the options we have early on. + +I have seen the pseries-2.12 changes in the qemu 2.11.1 stable release (didn't like them). +Especially for things like those that you mentioned "... I guess by that time pseries-2.12 to be changed to cap-htm=on by default" is the reason I can't pick a 2.12 type until 2.12 is final and released. + +We never can allow a case where pseries-2.12 != pseries-2.12 (for migrations and such). + +So at the moment the default pseries-bionic is based on 2.11 being the usual default of qemu 2.11 and the one that is meant to be (and stay) stable. + +So on the proposed change "3. Immediate fix can be Canonical defaults their machine type(pseries-bioic) to pseries-2.12" I'm reluctant to do so, as: + - only pseries would be 2.12 + - there is a high chance we end up with 2.12 != 2.12 down the road + + +Suggestion #1: +If you (=IBM as the authoritative entity for Power) decide that you want htm to be off in the 2.11 machine type in the Ubuntu 18.04 (=Bionic) release we can do that (as Bionic is not released yet we can still change it). + +But that would stay for the entire time of the Bionic release. +So pseries-bionic (the default) => pseries-2.11 (+htm off) will be the default until year 2023 + +Once (if) the host kernel at some point supports htm properly you can surely change the 2.12 type upstream, we would pick that up and later releases will default to a htm on case then. +Also people could run Bionic (which sets htm=off by default then) and run if needed with a htm=on override. + +But even all that would mean that e.g. a new qemu from the Ubuntu cloud archive in a year, would fail the same on a 18.04 base kernel. + +The real fix is to get that host support upstream (kernel) and get it in the Ubuntu kernel prior to the release of 18.04 - is that a realistic timeline, when do you expect this gets upstream? + +I hope those clarifications helped to see why I think just choosing the 2.12 type is no option. + +Thereby Counter-proposing: +1. in qemu we can make default pseries-bionic => pseries-2.11 (+htm off) if you want. + That makes things safe to use for now, but OTOH htm an opt-in feature on Ubuntu 18.04 + That would stay that way for the support time of 18.04 +OR +2. You get the kernel fix upstream asap and Ubuntu integrates before release of 18.04 + Then qemu/libvirt as is would work on P9 DD 2.2+ + (until that happens you can test with an override to set htm=off) + + +But any decision between #1/#2 depends very much on: +- the expected timeline of your kernel changes +- your preferenc in regard to the htm feature +So it is up to you to clarify on that as Andrew pointed out. + +------- Comment From <email address hidden> 2018-02-27 22:50 EDT------- +1. +If it's decided thatwe want to default to cap-htm=off, then that can be achieved by adding: +```smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;``` +to the spapr-bionic machine class init + +2. +What is the timeframe we are talking about here, a week/a month? It's hard to give a firm timeframe on the patches going upstream + +For 1. I mostly agree, the default is currently off in code and in 2.11 there is this for backwards compatability: + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON; + +We would have to +- Moving that "keep the old default" entry to 2.10 (to cover <=2.10) + spapr_machine_2_10_class_options + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON; +- And we would set it explicit off in 2.11 (which is what pseries-bionic refers to) + spapr_machine_2_11_class_options + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF; +- 2.12 we would not change IMHO, that might become whatever it becomes with 2.12 development + + +For #2 - this is a bug fix so it does not fall under the Feature Freeze (tomorrow). +But I don't know how much lead time the kernel team needs. +Given that kernel fixes are involved this clearly needs a kernel task for them to know about - adding ... + +@Kernel - please read the context - what is the last date you'd need to have this commit upstream by IBM to be able to pick it and still be in the initial 18.04 release kernel (not in -updates)? + +@IBM - how about this approach: +A) We switch the default to HTM=off in qemu "now" (as soon as you ack this) to be safe +B) If you get the kernel fixes upstream fast enough for the kernel Team to pick up in time: + B1) a fixed kernel will be pushed (before 18.04 release) + B2) we unroll this change in qemu (before 18.04 release) + +That way we would surely have something that "works" by default via (A) and if (B) is in time we can switch back to "working but with HTM enabled". +And if (B) is too late we will keep HTM disabled in the 2.11/Bionic machine type. + +------- Comment From <email address hidden> 2018-03-01 00:00 EDT------- +*** Bug 165240 has been marked as a duplicate of this bug. *** + +------- Comment From <email address hidden> 2018-03-01 01:22 EDT------- +Seems like the best option in my opinion + +Sorry, but to be sure is that a clear "yes please disable HTM by default in qemu on ppc64el for Ubuntu 18.04" ? + +Status changed to 'Confirmed' because the bug affects multiple users. + +------- Comment From <email address hidden> 2018-03-01 10:42 EDT------- +@paelzer yes, that is us agreeing with your plan +>A) We switch the default to HTM=off in qemu "now" (as soon as you ack this) to be safe +>B) If you get the kernel fixes upstream fast enough for the kernel Team to pick up in time: +>... + +Sorry for the delay. + +------- Comment From <email address hidden> 2018-03-01 12:41 EDT------- +(In reply to comment #27) +> @paelzer yes, that is us agreeing with your plan + +Does it mean that we are not going to have HTM support on KVM guests, even in POWER8? + +------- Comment From <email address hidden> 2018-03-01 13:17 EDT------- +(In reply to comment #28) +> (In reply to comment #27) +> > @paelzer yes, that is us agreeing with your plan +> +> Does it mean that we are not going to have HTM support on KVM guests, even +> in POWER8? + +you would use the 2.10 machine type for that, right? + +------- Comment From <email address hidden> 2018-03-01 15:07 EDT------- +(In reply to comment #29) +> (In reply to comment #28) +> > (In reply to comment #27) +> > > @paelzer yes, that is us agreeing with your plan +> > +> > Does it mean that we are not going to have HTM support on KVM guests, even +> > in POWER8? +> +> you would use the 2.10 machine type for that, right? +Right. This is about the new machine type. + +To the mini-discussion above - yes it would be default off on P8 as well then. +But by selecting an older machine type, or - even better - using the new type but with cap-htm=on + +Starting the fix in qemu early next week then (the one outlined as (A) in comment #4. + + +FYI: There is bug 1753826 which postponed the release/testing of this one a bit. +Currently in rebuild/test together. + +Fix pushed to bionic proposed, I'll track migration after it built and some time for the tests have passed. + +BTW - tests on P8 are already good on my side, and since the request from IBM came fro P9 I have to assume it will be good there. But e.g. cross release migration X->B and such I had tested explicitly to be sure. + +That said, please be aware that this will be a remaining "itch" for you at the current solution. +If somebody had guests on pre-Xenial it will have HTM enabled by default. +If those users migrate to a P9 system on Bionic they will still carry the feature of HTM being enabled and run into the issue, but there is nothing we can do about it other than getting your kernel fix completed and integrated. But I thought I make you aware to be sure. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu4 + +--------------- +qemu (1:2.11+dfsg-1ubuntu4) bionic; urgency=medium + + * d/p/ubuntu/define-ubuntu-machine-types.patch: Disable HTM feature for + ppc64el in spapr to let the defaults not fail on Power9 HW (LP: #1752026). + * d/p/ubuntu/lp1753826-memfd-fix-configure-test.patch: fix FTBFS with newer + versions of glibc >=2.27 (LP: #1753826) + + -- Christian Ehrhardt <email address hidden> Mon, 05 Mar 2018 16:43:01 +0100 + +------- Comment From <email address hidden> 2018-03-13 12:52 EDT------- +Paul's RFC patch to kernel, https://www.spinics.net/lists/kvm/msg165629.html + +Patch posted to lkml, but not yet accepted upstream. + +------- Comment From <email address hidden> 2018-03-20 16:38 EDT------- +I went to https://www.spinics.net/lists/kvm/msg165629.html but it only has source code change for the problem. + +Can Linux team build a patch against Ubuntu 18.04 kernel 4.15.0-12-generic for test team to install. Thanks + +------- Comment From <email address hidden> 2018-03-21 07:12 EDT------- +The latest version of the patches has been posted and is available at https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=35017. I will add a note when the series has been put in a maintainer's tree. + +------- Comment From <email address hidden> 2018-03-21 12:20 EDT------- +Gustavo, would you please add this patch to the Ubuntu kernel you created with the trap/HMI patches? + +------- Comment From <email address hidden> 2018-03-22 15:48 EDT------- +- Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily build below + +http://cdimages.ubuntu.com/ubuntu-server/daily/current/ + +- With today build, it no longer has the Transaction Memory error when start up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily build. + +------- Comment From <email address hidden> 2018-03-23 01:53 EDT------- +(In reply to comment #43) +> - Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily +> build below +> +> http://cdimages.ubuntu.com/ubuntu-server/daily/current/ +> +> - With today build, it no longer has the Transaction Memory error when start +> up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily +> build. + +(In reply to comment #43) +> - Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily +> build below +> +> http://cdimages.ubuntu.com/ubuntu-server/daily/current/ +> +> - With today build, it no longer has the Transaction Memory error when start +> up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily +> build. + +Hi Nguyen, + +Pauls patch(https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=35017) yet to get merged in linux master as of now{f36b7534b833 (HEAD -> master, upstream/master) Merge branch 'akpm' (patches from Andrew)} + +Does ubuntu daily kernel include custom patches? + +If it does not include custom patches and one reason why you do not hit the issue now, coz qemu disable cap-htm by default temporarily till the above kernel patches included, check if that is the case. + +you can confirm the TM patches are included by explicitly start qemu-kvm command with cap-htm=on + +Regards, +-Satheesh. + +------- Comment From <email address hidden> 2018-04-02 19:22 EDT------- +The patches that make it possible to use HTM in guests running on POWER9 processors are now in the PowerPC kernel maintainer tree and will be requested to get merged into kernel 4.17: + +681c617b7c42 KVM: PPC: Book3S HV: Work around TEXASR bug in fake suspend state +87a11bb6a7f7 KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode +4bb3c7a0208f KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 +7672691a08c8 powerpc/powernv: Provide a way to force a core into SMT4 mode +b5af4f279323 powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2 +9bbf0b576d32 powerpc: Free up CPU feature bits on 64-bit machines +dd0efb3f11cc powerpc: Book E: Remove unused CPU_FTR_L2CSR bit +c0d64cf9fefd powerpc: Use feature bit for RTC presence rather than timebase presence + +Fom Paul Mackerras: for a backport, we can probably avoid the feature bit rework, I hope, and just find two free CPU feature bits. If there aren't 2 free feature bits then let me know, we might be able to scavenge some that are only used on Book E or something. + +Since the kernel team is now investigating the integration of the kernel patches into bionic (the kernel bits are already Fix Committed), we should plan to get the temporary workaround again removed from qemu-kvm. +It's hard to time it in a way that the kernel changes are rolled-out and the qemu workaround got removed at the same time. +So this could lead to a short time of the qemu mitigation being reverted, but the kernel not yet being released, which would make you need the cap-htm=0ff workaround. But that way it would be much safer that both changes are available prior to the release of 18.04 Bionic. +Hence the question (to IBM) is if it would be okay to plan ahead and to get the qemu changes reverted back now? + +------- Comment From <email address hidden> 2018-04-04 04:18 EDT------- +(In reply to comment #48) +> Since the kernel team is now investigating the integration of the kernel +> patches into bionic (the kernel bits are already Fix Committed), we should +> plan to get the temporary workaround again removed from qemu-kvm. +> It's hard to time it in a way that the kernel changes are rolled-out and the +> qemu workaround got removed at the same time. +> So this could lead to a short time of the qemu mitigation being reverted, +> but the kernel not yet being released, which would make you need the +> cap-htm=0ff workaround. But that way it would be much safer that both +> changes are available prior to the release of 18.04 Bionic. +> Hence the question (to IBM) is if it would be okay to plan ahead and to get +> the qemu changes reverted back now? + +Yes, we need the qemu workaround to be removed. I see all required kernel patches are in master-next of bionic. Understand that both of these cannot be timed.. but having qemu changes revert today.. would we get updated kernel and qemu in tomorrows daily build? just wanted to understand what would be time window.. + +It's not possible to turn around a kernel that quickly. I intend to get a kernel with the fix uploaded bionic-proposed today, but it takes a few days at minimum to get it built, tested, and promoted to the -release pocket. + +@Seth - that is fine, for the Kernel we only need to rely on "will be out before Bionic release" and that looks good - don't feel pushed. +The updates were about asking IBM "If we assume the kernel fixes will be there, should we remove the qemu mitigation (as we can't remove it after Bionic release date)". + +------- Comment From <email address hidden> 2018-04-04 08:50 EDT------- +Hi Frank, + +First of all, thanks for caring about this bug and accepting the out-of-the-tree patches. + +You are right, the motivation to include this patchset is to re-enable the HTM in the KVM guests. So, we just need to schedule the fixes on both side. + +Here are some assumptions I have: + +1) If you need to revert the qemu-kvm "HTM off" patches right now, We can survive, since we have a internal kernel that contains the fix, and we can use this custom kernel in the mean time. Not a big deal. + +2) On the other side, I understand that the Final Freeze for Ubuntu will be in April 19th, so, we still have some time to release qemu, how long can we wait without affecting the time to we spend testing this package? + +3) Releasing the fixed kernel prior to the fixed qemu package would be better than the other way around. + +4) Can't we fix fix qemu now and keep it in the proposed until the kernel is released? + +Thanks! + +------- Comment From <email address hidden> 2018-04-04 08:55 EDT------- +One other possibility could be to have the changes going into the kernel and, then, remove the workaround from QEMU. QEMU with the workaround should continue to work with the kernel with the proper changes. HTM will be disabled in the guests, which would not be needed anymore, but would not block a VM from running. + +Anyway, I am OK either way. We need to make progress here and I understand this came in late. We need to have the fixes in the kernel and the workaround out of QEMU. If that means we will have a broken QEMU for few days, that would be OK. We can continue our tests with previous versions of kernel and QEMU until everything is settled in bionic repositories or disable HTM by hand when running tests. + +@Breno - I agree to #3 but since we have no hard ETA on the kernel I want to avoid punting qemu to the very last few days. History told me that always something happens/blocks and if we would miss GA we can't SRu to keep the final pseries-bionic type in sync. + +For #4 there is no good "keep in proposed" for the current Dev release. + +I discussed with lagarcia and JFH on IRC once more: +... +[15:02] <lagarcia_> cpaelzer, I am OK with that. TBH, we can live with QEMU removing the workaround now or after the kernel has been changed. +[15:05] <cpaelzer> there was a bug update by breno 3 minutes ago +[15:05] * cpaelzer is reading +[15:06] <cpaelzer> oh I see, and your comment - mirrored both at once +[15:06] <cpaelzer> my concern is that if anything comes up late +[15:06] <cpaelzer> we might end up with the qemu change not reverted +[15:07] <cpaelzer> as after release it becomes an issue +[15:07] <cpaelzer> and will no more be removable +[15:07] <cpaelzer> for consistency of the pseries-bionic type +[15:07] <jfh1> cpaelzer, lagarcia: ah - just saw the ticket update and a reply from Breno ... +[15:08] <cpaelzer> jfh1: do we have anything like an expected date by the kernel Team? +[15:08] <cpaelzer> I'd not want to wait with qemu later than end of this week TBH +[15:08] <cpaelzer> history teached me not to try changing things last minute +[15:08] <jfh1> cpaelzer: I agree - there is always the option to pin a package to prevent it from getting updated +[15:09] <jfh1> that can be an option for those guys who still need to KVM on P9 ... +[15:09] <cpaelzer> jfh1: lagarcia_: so are we agreeing that I'll revert the avoidance in qemu now considering the various constraints? +[15:09] * cpaelzer is +1 +[15:10] <jfh1> I think so ... +[15:12] <lagarcia_> cpaelzer, yep +[15:13] <lagarcia_> cpaelzer, when the patches reach bionic kernel, everything should work out of the box. Meanwhile, we can implement the workaround by hand. + + +With all that said, I'm including the revert of the current mitigation from the next qemu upload. + +Revert will be hanlded via bug 1761175 + +@ lagarcia and Breno: +People/tester who still need the patched qemu can prevent that from being upgraded by pinning it aka marking it as hold (https://help.ubuntu.com/community/PinningHowto). +Even in case of an accidental upgrade - it's easy to go again back to that version. + +------- Comment From <email address hidden> 2018-04-10 06:53 EDT------- +We have got the qemu build with htm-on today [April 10th]. Now we are able to start compat mode guests with htm-on.. apart from bug 166570 things look good. We can close this one. + +This bug was fixed in the package linux - 4.15.0-15.16 + +--------------- +linux (4.15.0-15.16) bionic; urgency=medium + + * linux: 4.15.0-15.16 -proposed tracker (LP: #1761177) + + * FFe: Enable configuring resume offset via sysfs (LP: #1760106) + - PM / hibernate: Make passing hibernate offsets more friendly + + * /dev/bcache/by-uuid links not created after reboot (LP: #1729145) + - SAUCE: (no-up) bcache: decouple emitting a cached_dev CHANGE uevent + + * Ubuntu18.04:POWER9:DD2.2 - Unable to start a KVM guest with default machine + type(pseries-bionic) complaining "KVM implementation does not support + Transactional Memory, try cap-htm=off" (kvm) (LP: #1752026) + - powerpc: Use feature bit for RTC presence rather than timebase presence + - powerpc: Book E: Remove unused CPU_FTR_L2CSR bit + - powerpc: Free up CPU feature bits on 64-bit machines + - powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2 + - powerpc/powernv: Provide a way to force a core into SMT4 mode + - KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 + - KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode + - KVM: PPC: Book3S HV: Work around TEXASR bug in fake suspend state + + * Important Kernel fixes to be backported for Power9 (kvm) (LP: #1758910) + - powerpc/mm: Fixup tlbie vs store ordering issue on POWER9 + + * Ubuntu 18.04 - IO Hang on some namespaces when running HTX with 16 + namespaces (Bolt / NVMe) (LP: #1757497) + - powerpc/64s: Fix lost pending interrupt due to race causing lost update to + irq_happened + + * fwts-efi-runtime-dkms 18.03.00-0ubuntu1: fwts-efi-runtime-dkms kernel module + failed to build (LP: #1760876) + - [Packaging] include the retpoline extractor in the headers + +linux (4.15.0-14.15) bionic; urgency=medium + + * linux: 4.15.0-14.15 -proposed tracker (LP: #1760678) + + * [Bionic] mlx4 ETH - mlnx_qos failed when set some TC to vendor + (LP: #1758662) + - net/mlx4_en: Change default QoS settings + + * AT_BASE_PLATFORM in AUXV is absent on kernels available on Ubuntu 17.10 + (LP: #1759312) + - powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT CPU features + + * Bionic update to 4.15.15 stable release (LP: #1760585) + - net: dsa: Fix dsa_is_user_port() test inversion + - openvswitch: meter: fix the incorrect calculation of max delta_t + - qed: Fix MPA unalign flow in case header is split across two packets. + - tcp: purge write queue upon aborting the connection + - qed: Fix non TCP packets should be dropped on iWARP ll2 connection + - sysfs: symlink: export sysfs_create_link_nowarn() + - net: phy: relax error checking when creating sysfs link netdev->phydev + - devlink: Remove redundant free on error path + - macvlan: filter out unsupported feature flags + - net: ipv6: keep sk status consistent after datagram connect failure + - ipv6: old_dport should be a __be16 in __ip6_datagram_connect() + - ipv6: sr: fix NULL pointer dereference when setting encap source address + - ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state + - mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic + - net: phy: Tell caller result of phy_change() + - ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes + - net sched actions: return explicit error when tunnel_key mode is not + specified + - ppp: avoid loop in xmit recursion detection code + - rhashtable: Fix rhlist duplicates insertion + - test_rhashtable: add test case for rhltable with duplicate objects + - kcm: lock lower socket in kcm_attach + - sch_netem: fix skb leak in netem_enqueue() + - ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event() + - net: use skb_to_full_sk() in skb_update_prio() + - net: Fix hlist corruptions in inet_evict_bucket() + - s390/qeth: free netdevice when removing a card + - s390/qeth: when thread completes, wake up all waiters + - s390/qeth: lock read device while queueing next buffer + - s390/qeth: on channel error, reject further cmd requests + - soc/fsl/qbman: fix issue in qman_delete_cgr_safe() + - dpaa_eth: fix error in dpaa_remove() + - dpaa_eth: remove duplicate initialization + - dpaa_eth: increment the RX dropped counter when needed + - dpaa_eth: remove duplicate increment of the tx_errors counter + - dccp: check sk for closed state in dccp_sendmsg() + - ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option() + - l2tp: do not accept arbitrary sockets + - net: ethernet: arc: Fix a potential memory leak if an optional regulator is + deferred + - net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY + interface + - net: fec: Fix unbalanced PM runtime calls + - net/iucv: Free memory obtained by kzalloc + - netlink: avoid a double skb free in genlmsg_mcast() + - net: Only honor ifindex in IP_PKTINFO if non-0 + - net: systemport: Rewrite __bcm_sysport_tx_reclaim() + - qede: Fix qedr link update + - skbuff: Fix not waking applications when errors are enqueued + - team: Fix double free in error path + - Linux 4.15.15 + + * Ubuntu 18.04 [ WSP DD2.2 with stop4 and stop5 enabled ]: kdump fails to + capture dump when smt=2 or off. (LP: #1758206) + - powerpc/crash: Remove the test for cpu_online in the IPI callback + - powernv/kdump: Fix cases where the kdump kernel can get HMI's + - powerpc/kdump: Fix powernv build break when KEXEC_CORE=n + + * [Intel Ubuntu 18.04 Bug] Null pointer dereference, when disconnecting RAID + rebuild target (LP: #1759279) + - md: document lifetime of internal rdev pointer. + + * [Feature]Crystal Ridge:add support for the platform capabilities NFIT sub- + table in ACPI 6.2A (LP: #1730829) + - ACPICA: ACPI 6.0A: Changes to the NFIT ACPI table + - acpi: nfit: Add support for detect platform CPU cache flush on power loss + - acpi: nfit: add persistent memory control flag for nd_region + - libnvdimm: expose platform persistence attribute for nd_region + - libnvdimm: re-enable deep flush for pmem devices via fsync() + - libnvdimm, nfit: fix persistence domain reporting + + * Allow multiple mounts of zfs datasets (LP: #1759848) + - SAUCE: Allow mounting datasets more than once (LP: #1759848) + + * Update Aquantia driver to fix various issues (LP: #1759303) + - net: aquantia: Eliminate AQ_DIMOF, replace with ARRAY_SIZE + - net: aquantia: Cleanup status flags accesses + - net: aquantia: Cleanup hardware access modules + - net: aquantia: Remove duplicate hardware descriptors declarations + - net: aquantia: Add const qualifiers for hardware ops tables + - net: aquantia: Simplify dependencies between pci modules + - net: aquantia: Eliminate aq_nic structure abstraction + - net: aquantia: Fix register definitions to linux style + - net: aquantia: Prepend hw access functions declarations with prefix + - net: aquantia: Fix internal stats calculation on rx + - net: aquantia: Introduce new device ids and constants + - net: aquantia: Introduce new AQC devices and capabilities + - net: aquantia: Convert hw and caps structures to const static pointers + - net: aquantia: Cleanup pci functions module + - net: aquantia: Remove create/destroy from hw ops + - net: aquantia: Change confusing no_ff_addr to more meaningful name + - net: aquantia: Introduce firmware ops callbacks + - net: aquantia: Introduce support for new firmware on AQC cards + - net: aquantia: Introduce global AQC hardware reset sequence + - net: aquantia: Report correct mediatype via ethtool + - net: aquantia: bump driver version to match aquantia internal numbering + - net: aquantia: Fix hardware reset when SPI may rarely hangup + - net: aquantia: Fix a regression with reset on old firmware + - net: aquantia: Change inefficient wait loop on fw data reads + - net: aquantia: Add tx clean budget and valid budget handling logic + - net: aquantia: Allow live mac address changes + - net: aquantia: Implement pci shutdown callback + - net: aquantia: driver version bump + + * ISST-LTE:KVM:Ubuntu1804:BostonLC:boslcp3: cpu hotplug on boslcp3g4 guest + dumping call traces continuously. (LP: #1759722) + - blk-mq: turn WARN_ON in __blk_mq_run_hw_queue into printk + + * ISST-LTE:KVM:Ubuntu18.04:BostonLC:boslcp3:boslcp3g3:Guest conosle hangs + after hotplug CPU add operation. (LP: #1759723) + - genirq/affinity: assign vectors to all possible CPUs + - blk-mq: simplify queue mapping & schedule with each possisble CPU + + * test_bpf fails (LP: #1756150) + - test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches + + * Bionic update to v4.15.14 stable release (LP: #1759655) + - MIPS: ralink: Remove ralink_halt() + - MIPS: ralink: Fix booting on MT7621 + - MIPS: lantiq: Fix Danube USB clock + - MIPS: lantiq: Enable AHB Bus for USB + - MIPS: lantiq: ase: Enable MFD_SYSCON + - iio: chemical: ccs811: Corrected firmware boot/application mode transition + - iio: st_pressure: st_accel: pass correct platform data to init + - iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock() + - ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit + - ALSA: aloop: Sync stale timer before release + - ALSA: aloop: Fix access to not-yet-ready substream via cable + - ALSA: hda - Force polling mode on CFL for fixing codec communication + - ALSA: hda/realtek - Fix speaker no sound after system resume + - ALSA: hda/realtek - Fix Dell headset Mic can't record + - ALSA: hda/realtek - Always immediately update mute LED with pin VREF + - mmc: core: Fix tracepoint print of blk_addr and blksz + - mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards + - mmc: block: fix updating ext_csd caches on ioctl call + - mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems + - mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433 + - mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs + - PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L + - ahci: Add PCI-id for the Highpoint Rocketraid 644L card + - lockdep: fix fs_reclaim warning + - clk: bcm2835: Fix ana->maskX definitions + - clk: bcm2835: Protect sections updating shared registers + - clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops + - RDMA/mlx5: Fix crash while accessing garbage pointer and freed memory + - Drivers: hv: vmbus: Fix ring buffer signaling + - pinctrl: samsung: Validate alias coming from DT + - Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table + - Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table + - Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 + - libata: fix length validation of ATAPI-relayed SCSI commands + - libata: remove WARN() for DMA or PIO command without data + - libata: don't try to pass through NCQ commands to non-NCQ devices + - libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs + - libata: Enable queued TRIM for Samsung SSD 860 + - libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs + - libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions + - libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version + - sched, cgroup: Don't reject lower cpu.max on ancestors + - cgroup: fix rule checking for threaded mode switching + - nfsd: remove blocked locks on client teardown + - media: tegra-cec: reset rx_buf_cnt when start bit detected + - hugetlbfs: check for pgoff value overflow + - h8300: remove extraneous __BIG_ENDIAN definition + - mm/vmalloc: add interfaces to free unmapped page table + - x86/mm: implement free pmd/pte page interfaces + - mm/khugepaged.c: convert VM_BUG_ON() to collapse fail + - mm/thp: do not wait for lock_page() in deferred_split_scan() + - mm/shmem: do not wait for lock_page() in shmem_unused_huge_shrink() + - Revert "mm: page_alloc: skip over regions of invalid pfns where possible" + - drm/vmwgfx: Fix black screen and device errors when running without fbdev + - drm/vmwgfx: Fix a destoy-while-held mutex problem. + - drm/radeon: Don't turn off DP sink when disconnected + - drm/amd/display: We shouldn't set format_default on plane as atomic driver + - drm/amd/display: Add one to EDID's audio channel count when passing to DC + - drm: Reject getfb for multi-plane framebuffers + - drm: udl: Properly check framebuffer mmap offsets + - mm/vmscan: wake up flushers for legacy cgroups too + - module: propagate error in modules_open() + - acpi, numa: fix pxm to online numa node associations + - ACPI / watchdog: Fix off-by-one error at resource assignment + - libnvdimm, {btt, blk}: do integrity setup before add_disk() + - brcmfmac: fix P2P_DEVICE ethernet address generation + - rtlwifi: rtl8723be: Fix loss of signal + - tracing: probeevent: Fix to support minus offset from symbol + - mtdchar: fix usage of mtd_ooblayout_ecc() + - mtd: nand: fsl_ifc: Fix nand waitfunc return value + - mtd: nand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0 + - mtd: nand: fsl_ifc: Read ECCSTAT0 and ECCSTAT1 registers for IFC 2.0 + - staging: ncpfs: memory corruption in ncp_read_kernel() + - can: peak/pcie_fd: fix echo_skb is occupied! bug + - can: peak/pcie_fd: remove useless code when interface starts + - can: ifi: Repair the error handling + - can: ifi: Check core revision upon probe + - can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack + - can: cc770: Fix queue stall & dropped RTR reply + - can: cc770: Fix use after free in cc770_tx_interrupt() + - tty: vt: fix up tabstops properly + - x86/entry/64: Don't use IST entry for #BP stack + - selftests/x86/ptrace_syscall: Fix for yet more glibc interference + - x86/vsyscall/64: Use proper accessor to update P4D entry + - x86/efi: Free efi_pgd with free_pages() + - posix-timers: Protect posix clock array access against speculation + - kvm/x86: fix icebp instruction handling + - x86/build/64: Force the linker to use 2MB page size + - x86/boot/64: Verify alignment of the LOAD segment + - hwmon: (k10temp) Only apply temperature offset if result is positive + - hwmon: (k10temp) Add temperature offset for Ryzen 1900X + - perf/x86/intel/uncore: Fix Skylake UPI event format + - perf stat: Fix CVS output format for non-supported counters + - perf/core: Fix ctx_event_type in ctx_resched() + - trace/bpf: remove helper bpf_perf_prog_read_value from tracepoint type + programs + - perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period() + - perf/x86/intel/uncore: Fix multi-domain PCI CHA enumeration bug on Skylake + servers + - iio: ABI: Fix name of timestamp sysfs file + - iio: imu: st_lsm6dsx: fix endianness in st_lsm6dsx_read_oneshot() + - iio: imu: st_lsm6dsx: introduce conf_lock mutex + - staging: android: ion: Zero CMA allocated memory + - kbuild: disable clang's default use of -fmerge-all-constants + - bpf: skip unnecessary capability check + - bpf, x64: increase number of passes + - Linux 4.15.14 + + * System fails to start (boot) on battery due to read-only root file-system + (LP: #1726930) // Bionic update to v4.15.14 stable release (LP: #1759655) + - libata: disable LPM for Crucial BX100 SSD 500GB drive + + * [Feature][CFL][ICL] [CNL]Thunderbolt support (Titan Ridge) (LP: #1730775) + - thunderbolt: Resume control channel after hibernation image is created + - thunderbolt: Serialize PCIe tunnel creation with PCI rescan + - thunderbolt: Handle connecting device in place of host properly + - thunderbolt: Do not overwrite error code when domain adding fails + - thunderbolt: Wait a bit longer for root switch config space + - thunderbolt: Wait a bit longer for ICM to authenticate the active NVM + - thunderbolt: Handle rejected Thunderbolt devices + - thunderbolt: Factor common ICM add and update operations out + - thunderbolt: Correct function name in kernel-doc comment + - thunderbolt: Add tb_switch_get() + - thunderbolt: Add tb_switch_find_by_route() + - thunderbolt: Add tb_xdomain_find_by_route() + - thunderbolt: Add constant for approval timeout + - thunderbolt: Move driver ready handling to struct icm + - thunderbolt: Add 'boot' attribute for devices + - thunderbolt: Add support for preboot ACL + - Documentation/admin-guide: fixes for thunderbolt.rst + - thunderbolt: Introduce USB only (SL4) security level + - thunderbolt: Add support for Intel Titan Ridge + + * QCA9377 requires more IRAM banks for its new firmware (LP: #1748345) + - ath10k: update the IRAM bank number for QCA9377 + + * nfp: fix disabling on hw-tc-offload in flower (LP: #1752828) + - nfp: bpf: require ETH table + - nfp: don't advertise hw-tc-offload on non-port netdevs + - nfp: forbid disabling hw-tc-offload on representors while offload active + + * Fix an issue that when system in S3, USB keyboard can't wake up the system. + (LP: #1759511) + - ACPI / PM: Allow deeper wakeup power states with no _SxD nor _SxW + + * retpoline hints: primary infrastructure and initial hints (LP: #1758856) + - [Packaging] retpoline -- add safe usage hint support + - [Packaging] retpoline-check -- only report additions + - [Packaging] retpoline -- widen indirect call/jmp detection + - [Packaging] retpoline -- elide %rip relative indirections + - [Packaging] retpoline -- clear hint information from packages + - SAUCE: apm -- annotate indirect calls within + firmware_restrict_branch_speculation_{start,end} + - SAUCE: EFI -- annotate indirect calls within + firmware_restrict_branch_speculation_{start,end} + - SAUCE: early/late -- annotate indirect calls in early/late initialisation + code + - SAUCE: vga_set_mode -- avoid jump tables + - [Config] retpoine -- switch to new format + + * zfs system process hung on container stop/delete (LP: #1754584) + - SAUCE: Fix non-prefaulted page deadlock (LP: #1754584) + - Revert "UBUNTU: SAUCE: Fix non-prefaulted page deadlock (LP: #1754584)" + - SAUCE: Fix non-prefaulted page deadlock (LP: #1754584) + + * Important KVM fixes for ppc64el (LP: #1759045) + - KVM: PPC: Book3S HV: Do SLB load/unload with guest LPCR value loaded + - KVM: PPC: Book3S HV: Fix handling of secondary HPTEG in HPT resizing code + - KVM: PPC: Book3S HV: Make HPT resizing work on POWER9 + - KVM: PPC: Book3S: Add MMIO emulation for VMX instructions + - KVM: PPC: Book3S: Fix compile error that occurs with some gcc versions + - KVM: PPC: Book3S HV: Fix trap number return from __kvmppc_vcore_entry + - KVM: PPC: Book3S HV: Fix duplication of host SLB entries + + * ubuntu_zram_smoke test will cause soft lockup on Artful ThunderX ARM64 + (LP: #1755073) + - SAUCE: crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK + + * Update to ocxl driver (LP: #1755161) + - ocxl: fix signed comparison with less than zero + - ocxl: Fix potential bad errno on irq allocation + - ocxl: Add get_metadata IOCTL to share OCXL information to userspace + + * CAPI Flash (cxlflash) update (LP: #1752672) + - scsi: cxlflash: Update cxl-specific arguments to generic cookie + - scsi: cxlflash: Explicitly cache number of interrupts per context + - scsi: cxlflash: Remove embedded CXL work structures + - scsi: cxlflash: Adapter context init can return error + - scsi: cxlflash: Staging to support future accelerators + - SAUCE: cxlflash: Preserve number of interrupts for master contexts + - SAUCE: cxlflash: Avoid clobbering context control register value + - SAUCE: cxlflash: Add argument identifier names + - SAUCE: cxlflash: Introduce OCXL backend + - SAUCE: cxlflash: Hardware AFU for OCXL + - SAUCE: cxlflash: Read host function configuration + - SAUCE: cxlflash: Setup function acTag range + - SAUCE: cxlflash: Read host AFU configuration + - SAUCE: cxlflash: Setup AFU acTag range + - SAUCE: cxlflash: Setup AFU PASID + - SAUCE: cxlflash: Adapter context support for OCXL + - SAUCE: cxlflash: Use IDR to manage adapter contexts + - SAUCE: cxlflash: Support adapter file descriptors for OCXL + - SAUCE: cxlflash: Support adapter context discovery + - SAUCE: cxlflash: Support image reload policy modification + - SAUCE: cxlflash: MMIO map the AFU + - SAUCE: cxlflash: Support starting an adapter context + - SAUCE: cxlflash: Support process specific mappings + - SAUCE: cxlflash: Support AFU state toggling + - SAUCE: cxlflash: Support reading adapter VPD data + - SAUCE: cxlflash: Setup function OCXL link + - SAUCE: cxlflash: Setup OCXL transaction layer + - SAUCE: cxlflash: Support process element lifecycle + - SAUCE: cxlflash: Support AFU interrupt management + - SAUCE: cxlflash: Support AFU interrupt mapping and registration + - SAUCE: cxlflash: Support starting user contexts + - SAUCE: cxlflash: Support adapter context polling + - SAUCE: cxlflash: Support adapter context reading + - SAUCE: cxlflash: Support adapter context mmap and release + - SAUCE: cxlflash: Support file descriptor mapping + - SAUCE: cxlflash: Introduce object handle fop + - SAUCE: cxlflash: Setup LISNs for user contexts + - SAUCE: cxlflash: Setup LISNs for master contexts + - SAUCE: cxlflash: Update synchronous interrupt status bits + - SAUCE: cxlflash: Introduce OCXL context state machine + - SAUCE: cxlflash: Register for translation errors + - SAUCE: cxlflash: Support AFU reset + - SAUCE: cxlflash: Enable OCXL operations + + * [Feature][CFL] Enable pmc_core driver for H, S, and U SKUs (LP: #1730770) + - platform/x86: intel_pmc_core: Remove unused EXPORTED API + - platform/x86: intel_pmc_core: Change driver to a module + - platform/x86: intel_pmc_core: Fix file permission warnings + - platform/x86: intel_pmc_core: Refactor debugfs entries + - platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration + - platform/x86: intel_pmc_core: Convert to ICPU macro + - platform/x86: intel_pmc_core: Remove unused header file + - ACPI / LPIT: Export lpit_read_residency_count_address() + - platform/x86: intel_pmc_core: Read base address from LPIT + - x86/cpu: Add Cannonlake to Intel family + - platform/x86: intel_pmc_core: Add CannonLake PCH support + - platform/x86: intel_pmc_core: Special case for Coffeelake + + * Cpu utilization showing system time for kvm guests (performance) (sysstat) + (LP: #1755979) + - KVM: PPC: Book3S HV: Fix guest time accounting with VIRT_CPU_ACCOUNTING_GEN + + * [Artful][Wyse 3040] System hang when trying to enable an offlined CPU core + (LP: #1736393) + - SAUCE: drm/i915:Don't set chip specific data + - SAUCE: drm/i915: make previous commit affects Wyse 3040 only + + * [Bug] ISH support for CFL-H (LP: #1739522) + - HID: intel-ish-hid: Enable Cannon Lake and Coffee Lake laptop/desktop + + * ath9k can't connect to wifi AP (LP: #1727228) + - ath9k: add MSI support + - ath9k: add a quirk to set use_msi automatically + + * [P9,Power NV][Witherspoon][Ubuntu 18.04][Perf] : PMU events by name it is + not listed under perf list (LP: #1755470) + - iperf vendor events: Use more flexible pattern matching for CPU + identification for mapfile.csv + + * zed process consuming 100% cpu (LP: #1751796) + - SAUCE: Fix ioctl loop-spin in zed (LP: #1751796) + + * Bionic update to 4.15.13 stable release (LP: #1758886) + - scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura + controllers + - staging: android: ashmem: Fix possible deadlock in ashmem_ioctl + - drm/amdgpu: use polling mem to set SDMA3 wptr for VF + - Bluetooth: hci_qca: Avoid setup failure on missing rampatch + - Bluetooth: btqcomsmd: Fix skb double free corruption + - cpufreq: longhaul: Revert transition_delay_us to 200 ms + - media: c8sectpfe: fix potential NULL pointer dereference in + c8sectpfe_timer_interrupt + - drm/msm: fix leak in failed get_pages + - IB/ipoib: Warn when one port fails to initialize + - RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() + - hv_netvsc: Fix the receive buffer size limit + - hv_netvsc: Fix the TX/RX buffer default sizes + - tcp: allow TLP in ECN CWR + - spi: sh-msiof: Avoid writing to registers from spi_master.setup() + - libbpf: prefer global symbols as bpf program name source + - rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. + - rtlwifi: always initialize variables given to RT_TRACE() + - media: bt8xx: Fix err 'bt878_probe()' + - ath10k: handling qos at STA side based on AP WMM enable/disable + - media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart + - qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect + - tty: goldfish: Enable 'earlycon' only if built-in + - serial: 8250_dw: Disable clock on error + - cros_ec: fix nul-termination for firmware build info + - watchdog: Fix potential kref imbalance when opening watchdog + - watchdog: Fix kref imbalance seen if handle_boot_enabled=0 + - platform/chrome: Use proper protocol transfer function + - dmaengine: zynqmp_dma: Fix race condition in the probe + - drm/tilcdc: ensure nonatomic iowrite64 is not used + - mmc: avoid removing non-removable hosts during suspend + - mmc: block: fix logical error to avoid memory leak + - /dev/mem: Add bounce buffer for copy-out + - net: phy: meson-gxl: check phy_write return value + - sfp: fix EEPROM reading in the case of non-SFF8472 SFPs + - sfp: fix non-detection of PHY + - media: s5p-mfc: Fix lock contention - request_firmware() once + - rtc: ac100: Fix multiple race conditions + - IB/ipoib: Avoid memory leak if the SA returns a different DGID + - RDMA/cma: Use correct size when writing netlink stats + - IB/umem: Fix use of npages/nmap fields + - iser-target: avoid reinitializing rdma contexts for isert commands + - bpf/cgroup: fix a verification error for a CGROUP_DEVICE type prog + - vgacon: Set VGA struct resource types + - omapdrm: panel: fix compatible vendor string for td028ttec1 + - mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable + - drm/omap: DMM: Check for DMM readiness after successful transaction commit + - pty: cancel pty slave port buf's work in tty_release + - coresight: Fix disabling of CoreSight TPIU + - PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit + - PCI: endpoint: Fix find_first_zero_bit() usage + - PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures + - media: davinci: fix a debug printk + - clk: check ops pointer on clock register + - dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000 + - clk: use round rate to bail out early in set_rate + - pinctrl: Really force states during suspend/resume + - pinctrl: rockchip: enable clock when reading pin direction register + - iommu/vt-d: clean up pr_irq if request_threaded_irq fails + - ip6_vti: adjust vti mtu according to mtu of lower device + - ip_gre: fix error path when erspan_rcv failed + - ip_gre: fix potential memory leak in erspan_rcv + - soc: qcom: smsm: fix child-node lookup + - RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS + - ARM: dts: aspeed-evb: Add unit name to memory node + - nfsd4: permit layoutget of executable-only files + - clk: at91: pmc: Wait for clocks when resuming + - clk: Don't touch hardware when reparenting during registration + - clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() + - clk: si5351: Rename internal plls to avoid name collisions + - crypto: artpec6 - set correct iv size for gcm(aes) + - hwrng: core - Clean up RNG list when last hwrng is unregistered + - dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 + - IB/mlx5: Fix integer overflows in mlx5_ib_create_srq + - IB/mlx5: Fix out-of-bounds read in create_raw_packet_qp_rq + - RDMA/vmw_pvrdma: Fix usage of user response structures in ABI file + - serial: 8250_pci: Don't fail on multiport card class + - RDMA/core: Do not use invalid destination in determining port reuse + - clk: migrate the count of orphaned clocks at init + - RDMA/ucma: Fix access to non-initialized CM_ID object + - RDMA/ucma: Don't allow join attempts for unsupported AF family + - Linux 4.15.13 + + * Ubuntu18.04:PowerPC - Set Transparent Huge Pages (THP) by default to + "always" (LP: #1753708) + - Config: Set TRANSPARENT_HUGEPAGE_ALWAYS=y on ppc64el + + * Bionic update to 4.15.12 stable release (LP: #1757465) + - x86/cpufeatures: Add Intel Total Memory Encryption cpufeature + - x86/cpufeatures: Add Intel PCONFIG cpufeature + - selftests/x86/entry_from_vm86: Exit with 1 if we fail + - selftests/x86/entry_from_vm86: Add test cases for POPF + - x86/vm86/32: Fix POPF emulation + - x86/speculation, objtool: Annotate indirect calls/jumps for objtool on + 32-bit kernels + - x86/speculation: Remove Skylake C2 from Speculation Control microcode + blacklist + - KVM: x86: Fix device passthrough when SME is active + - x86/mm: Fix vmalloc_fault to use pXd_large + - parisc: Handle case where flush_cache_range is called with no context + - ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() + - ALSA: hda - Revert power_save option default value + - ALSA: seq: Fix possible UAF in snd_seq_check_queue() + - ALSA: seq: Clear client entry before deleting else at closing + - drm/nouveau/bl: Fix oops on driver unbind + - drm/nouveau/mmu: ALIGN_DOWN correct variable + - drm/amdgpu: fix prime teardown order + - drm/radeon: fix prime teardown order + - drm/amdgpu/dce: Don't turn off DP sink when disconnected + - fs: Teach path_connected to handle nfs filesystems with multiple roots. + - KVM: arm/arm64: Reduce verbosity of KVM init log + - KVM: arm/arm64: Reset mapped IRQs on VM reset + - kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3 + - KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid + - lock_parent() needs to recheck if dentry got __dentry_kill'ed under it + - fs/aio: Add explicit RCU grace period when freeing kioctx + - fs/aio: Use RCU accessors for kioctx_table->table[] + - RDMAVT: Fix synchronization around percpu_ref + - irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis + - nvme: fix subsystem multiple controllers support check + - xfs: preserve i_rdev when recycling a reclaimable inode + - btrfs: Fix NULL pointer exception in find_bio_stripe + - btrfs: add missing initialization in btrfs_check_shared + - btrfs: alloc_chunk: fix DUP stripe size handling + - btrfs: Fix use-after-free when cleaning up fs_devs with a single stale + device + - btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes + - btrfs: Fix memory barriers usage with device stats counters + - scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que + - scsi: qla2xxx: Fix NULL pointer access for fcport structure + - scsi: qla2xxx: Fix logo flag for qlt_free_session_done() + - scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure + - usb: dwc2: fix STM32F7 USB OTG HS compatible + - dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding + - USB: gadget: udc: Add missing platform_device_put() on error in + bdc_pci_probe() + - usb: dwc3: Fix GDBGFIFOSPACE_TYPE values + - usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode + - usb: dwc3: of-simple: fix oops by unbalanced clk disable call + - usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove() + - phy: phy-brcm-usb: Fix two DT properties to match bindings doc + - phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271 + - phy: phy-brcm-usb-init: DRD mode can cause crash on startup + - phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled + - Linux 4.15.12 + + * cxl: Fix timebase synchronization status on POWER9 missing (CAPI) + (LP: #1757228) + - cxl: Fix timebase synchronization status on P9 + + * [Feature][GLK] Enable L2 CDP (Code and Data Prioritization) (LP: #1737873) + - x86/intel_rdt: Enumerate L2 Code and Data Prioritization (CDP) feature + - x86/intel_rdt: Add command line parameter to control L2_CDP + + * [Feature] Crystal Ridge-Restrict DAX to configurations with struct page + (LP: #1751724) + - mm, dax: introduce pfn_t_special() + - ext2: auto disable dax instead of failing mount + - ext4: auto disable dax instead of failing mount + - dax: require 'struct page' by default for filesystem dax + - Config: Enable CONFIG_FS_DAX_LIMITED + + * Bionic update to 4.15.11 stable release (LP: #1756978) + - x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 + - ASoC: sun4i-i2s: Fix RX slot number of SUN8I + - ASoC: sgtl5000: Fix suspend/resume + - ASoC: wm_adsp: For TLV controls only register TLV get/set + - ASoC: rt5651: Fix regcache sync errors on resume + - usb: host: xhci-rcar: add support for r8a77965 + - xhci: Fix front USB ports on ASUS PRIME B350M-A + - xhci: fix endpoint context tracer output + - serial: sh-sci: prevent lockup on full TTY buffers + - tty/serial: atmel: add new version check for usart + - uas: fix comparison for error code + - staging: comedi: fix comedi_nsamples_left. + - staging: android: ashmem: Fix lockdep issue during llseek + - scsi: sd_zbc: Fix potential memory leak + - USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h + - usbip: vudc: fix null pointer dereference on udc->lock + - usb: quirks: add control message delay for 1b1c:1b20 + - usb: usbmon: Read text within supplied buffer size + - usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb() + - usb: dwc3: Fix lock-up on ID change during system suspend/resume + - serial: 8250_pci: Add Brainboxes UC-260 4 port serial device + - serial: core: mark port as initialized in autoconfig + - earlycon: add reg-offset to physical address before mapping + - dm mpath: fix passing integrity data + - Revert "btrfs: use proper endianness accessors for super_copy" + - gfs2: Clean up {lookup,fillup}_metapath + - gfs2: Fixes to "Implement iomap for block_map" (2) + - drm/panel: rpi-touchscreen: propagate errors in rpi_touchscreen_i2c_read() + - spi: imx: Fix failure path leak on GPIO request error correctly + - HID: multitouch: Only look at non touch fields in first packet of a frame + - KVM: PPC: Book3S HV: Avoid shifts by negative amounts + - drm/edid: set ELD connector type in drm_edid_to_eld() + - dma-buf/fence: Fix lock inversion within dma-fence-array + - video/hdmi: Allow "empty" HDMI infoframes + - KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix() + - HID: elo: clear BTN_LEFT mapping + - iwlwifi: mvm: rs: don't override the rate history in the search cycle + - ARM: dts: koelsch: Move cec_clock to root node + - clk: meson: gxbb: fix wrong clock for SARADC/SANA + - ARM: dts: exynos: Correct Trats2 panel reset line + - drm/amdgpu: fix get_max_engine_clock_in_mhz + - staging: rtl8822be: fix missing null check on dev_alloc_skb return + - typec: tcpm: fusb302: Resolve out of order messaging events + - USB: ledtrig-usbport: fix of-node leak + - dt-bindings: serial: Add common rs485 binding for RTS polarity + - sched: Stop switched_to_rt() from sending IPIs to offline CPUs + - sched: Stop resched_cpu() from sending IPIs to offline CPUs + - crypto: chelsio - Fix an error code in chcr_hash_dma_map() + - crypto: ecc - Fix NULL pointer deref. on no default_rng + - crypto: keywrap - Add missing ULL suffixes for 64-bit constants + - crypto: cavium - fix memory leak on info + - test_firmware: fix setting old custom fw path back on exit + - drm/vblank: Fix vblank timestamp debugs + - net: ieee802154: adf7242: Fix bug if defined DEBUG + - rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe() + - perf report: Fix -D output for user metadata events + - net: xfrm: allow clearing socket xfrm policies. + - gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags simultaneously + - mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() + - net: thunderx: Set max queue count taking XDP_TX into account + - ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin + - ARM: dts: omap3-n900: Fix the audio CODEC's reset pin + - mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 + - userns: Don't fail follow_automount based on s_user_ns + - xfrm: Fix xfrm_replay_overflow_offload_esn + - leds: pm8058: Silence pointer to integer size warning + - bpf: fix stack state printing in verifier log + - power: supply: sbs-message: double left shift bug in sbsm_select() + - power: supply: ab8500_charger: Fix an error handling path + - power: supply: ab8500_charger: Bail out in case of error in + 'ab8500_charger_init_hw_registers()' + - drm/etnaviv: make THERMAL selectable + - iio: adc: ina2xx: Shift bus voltage register to mask flag bits + - iio: health: max30102: Add power enable parameter to get_temp function + - ath10k: update tdls teardown state to target + - cpufreq: Fix governor module removal race + - KVM: X86: Restart the guest when insn_len is zero and SEV is enabled + - drm/amdgpu:fix random missing of FLR NOTIFY + - scsi: ses: don't ask for diagnostic pages repeatedly during probe + - pwm: stmpe: Fix wrong register offset for hwpwm=2 case + - drm/sun4i: Fix format mask in DE2 driver + - pinctrl: sh-pfc: r8a7791: Add can_clk function + - pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using + STP_ISEN_1_D + - perf annotate: Fix unnecessary memory allocation for s390x + - perf annotate: Fix objdump comment parsing for Intel mov dissassembly + - iwlwifi: mvm: avoid dumping assert log when device is stopped + - drm/amdgpu:fix virtual dce bug + - drm/amdgpu: fix amdgpu_sync_resv v2 + - bnxt_en: Uninitialized variable in bnxt_tc_parse_actions() + - clk: qcom: msm8916: fix mnd_width for codec_digcodec + - mwifiex: cfg80211: do not change virtual interface during scan processing + - ath10k: fix invalid STS_CAP_OFFSET_MASK + - tools/usbip: fixes build with musl libc toolchain + - spi: sun6i: disable/unprepare clocks on remove + - bnxt_en: Don't print "Link speed -1 no longer supported" messages. + - scsi: core: scsi_get_device_flags_keyed(): Always return device flags + - scsi: devinfo: apply to HP XP the same flags as Hitachi VSP + - scsi: dh: add new rdac devices + - clk: renesas: r8a77970: Add LVDS clock + - staging: fsl-dpaa2/eth: Fix access to FAS field + - media: vsp1: Prevent suspending and resuming DRM pipelines + - dm raid: fix raid set size revalidation + - media: cpia2: Fix a couple off by one bugs + - media: davinci: vpif_capture: add NULL check on devm_kzalloc return value + - virtio_net: Disable interrupts if napi_complete_done rescheduled napi + - net: sched: drop qdisc_reset from dev_graft_qdisc + - veth: set peer GSO values + - drm/amdkfd: Fix memory leaks in kfd topology + - powerpc/64: Don't trace irqs-off at interrupt return to soft-disabled + context + - arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset + - agp/intel: Flush all chipset writes after updating the GGTT + - mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED + - mac80211: remove BUG() when interface type is invalid + - crypto: caam/qi - use correct print specifier for size_t + - ASoC: nuc900: Fix a loop timeout test + - mmc: mmc_test: Ensure command queue is disabled for testing + - Fix misannotated out-of-line _copy_to_user() + - ipvlan: add L2 check for packets arriving via virtual devices + - rcutorture/configinit: Fix build directory error message + - locking/locktorture: Fix num reader/writer corner cases + - ima: relax requiring a file signature for new files with zero length + - IB/mlx5: revisit -Wmaybe-uninitialized warning + - dmaengine: qcom_hidma: check pending interrupts + - drm/i915/glk: Disable Guc and HuC on GLK + - Linux 4.15.11 + - Config: Enable CONFIG_DRM_ETNAVIV_THERMAL=y + + * [FFE][Feature] KVM CLX avx512_vnni (LP: #1739665) + - KVM: x86: add support for UMIP + - KVM: Expose new cpu features to guest + + * Ubuntu18.04[P9 DD2.2 Boston]:Unable to boot power8 compat mode + guests(ubuntu14.04.5) (kvm) (LP: #1756254) + - KVM: PPC: Book3S HV: Allow HPT and radix on the same core for POWER9 v2.2 + + * Allow hugepage backing for "p8compat" mode kvm guests (LP: #1754206) + - KVM: PPC: Book3S HV: Fix VRMA initialization with 2MB or 1GB memory backing + + * [Bug][KVM][Crystal Ridge] Terrible performance of vNVDIMM on QEMU with + device DAX backend (LP: #1745899) + - x86/mm: add a function to check if a pfn is UC/UC-/WC + - KVM: MMU: consider host cache mode in MMIO page check + + * nfp: read ME frequency from vNIC ctrl memory (LP: #1752818) + - nfp: add TLV capabilities to the BAR + - nfp: read ME frequency from vNIC ctrl memory + - nfp: fix TLV offset calculation + + * Miscellaneous Ubuntu changes + - [Packaging] skip cloud tools packaging when not building package + - [Packaging] final-checks -- remove check for empty retpoline files + + -- Seth Forshee <email address hidden> Wed, 04 Apr 2018 08:26:19 -0500 + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +This bug was erroneously marked for verification in bionic; verification is not required and verification-needed-bionic is being removed. + diff --git a/results/classifier/105/KVM/1754038 b/results/classifier/105/KVM/1754038 new file mode 100644 index 00000000..d3a3d107 --- /dev/null +++ b/results/classifier/105/KVM/1754038 @@ -0,0 +1,354 @@ +KVM: 0.922 +other: 0.864 +device: 0.855 +graphic: 0.853 +assembly: 0.847 +vnc: 0.839 +instruction: 0.825 +boot: 0.812 +socket: 0.809 +mistranslation: 0.797 +network: 0.792 +semantic: 0.790 + +ARM M: Systick first wrap delayed (qemu-timers/icount prb?) + +When running this kind of code with qemu: + +static void SysTickISR(void) +{ + printf("SysTick\n"); +} + +void main() +{ + volatile int i, j; + printf("setup timer\n"); + *(uint32_t*) 0xE000E014 = 0x8FFFFF; //reload value + *(uint32_t*) 0xE000E018 = 0; //force reload + *(uint32_t*) 0xE000E010 = 7; //cpu clk + ISR + enable + + for (j = 0; j < 0x100; j++) { + for (i = 0; i < 0x100000; i++) + ; + printf("cnt %08x -- %8x\n", *(uint32_t*) 0xE000E018, *(uint32_t*)0xE000E010); + } +} + +I get the following output (comments added after '#'): + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +cnt 00000000 -- 7 <--- problem here, systick should wrap and raise isr +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +SysTick <--- delayed isr occuring here +cnt 000986e0 -- 10007 +SysTick +cnt 00865290 -- 10007 <---- then running fine as long as regs not modified +cnt 00731e51 -- 7 +cnt 005fea27 -- 7 +cnt 004cb5ff -- 7 +cnt 003981d6 -- 7 +cnt 00264dad -- 7 +cnt 00131984 -- 7 +SysTick +cnt 008fe545 -- 10007 +cnt 007cb106 -- 7 +cnt 00697cdd -- 7 +cnt 005648b4 -- 7 +cnt 0043148b -- 7 +cnt 002fe061 -- 7 +cnt 001cac38 -- 7 +cnt 00097810 -- 7 +SysTick +cnt 008643d6 -- 10007 +cnt 00730f97 -- 7 +cnt 005fdb6d -- 7 +cnt 004ca745 -- 7 +cnt 0039731c -- 7 +cnt 00263ef3 -- 7 +cnt 00130aca -- 7 +SysTick +cnt 008fd68b -- 10007 +cnt 007ca24c -- 7 +cnt 00696e23 -- 7 +cnt 005639fa -- 7 +cnt 004305d1 -- 7 +cnt 002fd1a8 -- 7 +cnt 001c9d7f -- 7 +cnt 00096956 -- 7 +SysTick +cnt 0086351d -- 10007 +cnt 007300dd -- 7 +cnt 005fccb4 -- 7 +cnt 004c988c -- 7 +cnt 00396463 -- 7 +cnt 00263039 -- 7 +cnt 0012fc10 -- 7 +[...] + +Command line and version: +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -monitor stdio -serial file:/dev/pts/6 -icount 4 -cpu cortex-m4 +QEMU 2.11.50 + +I am compiling from git repo, head is: +commit f32408f3b472a088467474ab152be3b6285b2d7b +Author: Daniel P. Berrangé <email address hidden> +Date: Tue Mar 6 13:43:17 2018 +0000 + +Config options: +./configure --target-list=arm-softmmu --enable-debug --disable-slirp --enable-tcg-interpreter --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native + + +Not working with git tag 2.10.0 (almost same config) + +Working with stock qemu-arm 2.5.0 from Ubuntu 16.04. + +I started investigating, though I am not familiar with qemu code and I could see that the execution is not geting out of qemu_tcg_rr_cpu_thread_fn() 'while' loop and timers are not triggered because the values in cpu->icount_extra or cpu->icount_budget are not to modified accordingly after the timer is set (host side) when the systick register is written (target side). + +Delay between the counter hitting zero and the ISR firing is architecturally permitted (the interrupt must be recognized in finite time or at a context synchronizing event, but not necessarily at the same 'clock tick' that the counter hits zero). If you want to ensure that an interrupt has been taken before you read the counter value, you need to use an ISB instruction in your loop. + +(There are also some buggy behaviours in our systick device implementation, but in this case I don't think you're running into them.) + + +I tried to insert an ISB in the loop but I get more or less the same result. + +However, I guess from your response that I did not explain the problem well enough. I understand that qemu will not be cycle accurate, however, here, we are not even "one million cycles accurate"! The counter would have the time to wrap twice before qemu is taking into account the first ISR... and if we check the following ISR time, we have a good accuracy, so I still think this is a bug. + +Morever, as said above, if I test with qemu 2.5.0 from Ubuntu package I get an accurate behavior: + +setup timer +cnt 00799997 -- 7 +cnt 0063323b -- 7 +cnt 004ccade -- 7 +cnt 00366383 -- 7 +cnt 001ffc26 -- 7 +cnt 000994ca -- 7 +SysTick +cnt 00832d5e -- 10007 +cnt 006cc5eb -- 7 +cnt 00565e8f -- 7 +cnt 003ff733 -- 7 +cnt 00298fd7 -- 7 +cnt 0013287b -- 7 +SysTick +cnt 008cc108 -- 10007 +cnt 00765996 -- 7 +cnt 005ff239 -- 7 +cnt 00498add -- 7 +cnt 00332381 -- 7 +cnt 001cbc24 -- 7 +cnt 000654c8 -- 7 +SysTick +cnt 007fed5c -- 10007 +cnt 006985ea -- 7 +cnt 00531e8d -- 7 +cnt 003cb731 -- 7 +cnt 00264fd5 -- 7 +cnt 000fe879 -- 7 +SysTick +cnt 0089810c -- 10007 +cnt 0073199a -- 7 +cnt 005cb23d -- 7 +[...] + +So here I would suspect either a regression in the code or a wrong combination of options when I compile it myself. I am trying to recompile version 2.5 myself to sort this out but I am running in other errors. + + + +OK, I will see if I can find some time to investigate this. Can you attach your guest binary, please? + + +Please find the binary attached. + +I have been trying several versions and it looks like the regression occured between v2.8.0 and v2.9.0. + + +Ok I spent more time trying to identify the commits giving problem. + +So before 8d04fb5, qemu is executing the binary as expected: + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +SysTick +cnt 00865f9c -- 10007 +cnt 00732b5c -- 7 +cnt 005ff733 -- 7 +cnt 004cc30a -- 7 +[...] + + +Then, after this commit "tcg: drop global lock during TCG code execution": + +https://git.qemu.org/?p=qemu.git;a=commit;h=8d04fb55dec381bc5105cb47f29d918e579e8cbd + +things start to look bad (but not the same way I first ran into): + +setup timer +SysTick +cnt 00000000 -- 10007 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 008ff3e3 -- 7 +cnt 007cbfba -- 7 +cnt 00698b92 -- 7 +cnt 00565768 -- 7 +cnt 0043233f -- 7 +cnt 002fef16 -- 7 +cnt 001cbaed -- 7 +cnt 000986c5 -- 7 +SysTick +cnt 0086528b -- 10007 +cnt 00731e4c -- 7 +cnt 005fea23 -- 7 +cnt 004cb5fa -- 7 +cnt 003981d1 -- 7 +[...] + +Then, not long after, this commit changes a little bit the prb "icount: process QEMU_CLOCK_VIRTUAL timers in vCPU thread" + +https://git.qemu.org/?p=qemu.git;a=commit;h=6b8f0187a4d7c263e356302f8d308655372a4b5b + +Output then looks like: + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +SysTick +cnt 000986e0 -- 10007 +SysTick +cnt 00865290 -- 10007 +cnt 00731e51 -- 7 +cnt 005fea27 -- 7 +[...] + +... and it seems this very problem has been occurring up to now. + +I am here using the binary attached, with this command line: + +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -serial file:$(tty) -icount 4 -cpu cortex-m4 + +And with these build options: + +./configure --target-list=arm-softmmu --disable-slirp --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-tcmalloc --disable-jemalloc --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-pie --extra-cflags=-mtune=native + +Note that, to prevent MTTCG/icount error, we must modify configure for the arm target with: + + mttcg="no" + + + + +I finally implemented a workaround to correct the problem: + +in cpus.c : qemu_start_warp_timer(), in the "if (deadline > 0) { ... }" part, I added: + + CPUState *cpu; + CPU_FOREACH(cpu) { + atomic_mb_set(&cpu->exit_request, 1); + } + +I do not understand more than 5% of the code I am messing up, so this hack is probably broken... + +Then I tested a bit more the code with different testcases... and I found a new bug when writing a reload value smaller than the current counter (the counter will then read as 0). It is due to this piece of code in armv7m_systick.c : systick_read() : + + /* The interrupt in triggered when the timer reaches zero. + However the counter is not reloaded until the next clock + tick. This is a hack to return zero during the first tick. */ + if (val > s->reload) { + val = 0; + } + +Well this is not really a prb for me with normal code, and it looks like under control, but I can open another bug if needed. + + + +The workaround I described above is actually not the good one, because of this check occurring just before: + + if (!all_cpu_threads_idle()) { + return; + } + +The exit request setting must be done before, so my code looks like this: + + + CPUState *cpu; + CPU_FOREACH(cpu) { + atomic_mb_set(&cpu->exit_request, 1); + } + + if (!all_cpu_threads_idle()) { + return; + } + +(version is v2.11.0-2122-g9fa673c-dirty) + + + + +Thanks for the test case; that was very useful. I've sent a patch which should fix this bug: +https://patchwork.ozlabs.org/patch/895693/ + +The "writing a reload value smaller than the current counter" bug is one of the ones I know about in our systick implementation. I may have time to overhaul that code in the 2.13 timeframe. + + +Hi Peter, + +I just tested your patch, I confirm it is also working on my side. Many thanks. + +Now fixed in master, commit c52e7132d7c885, and will be in 2.12.0. + diff --git a/results/classifier/105/KVM/1756728 b/results/classifier/105/KVM/1756728 new file mode 100644 index 00000000..12061451 --- /dev/null +++ b/results/classifier/105/KVM/1756728 @@ -0,0 +1,35 @@ +KVM: 0.838 +device: 0.794 +graphic: 0.772 +instruction: 0.770 +mistranslation: 0.710 +other: 0.695 +semantic: 0.610 +network: 0.605 +assembly: 0.575 +socket: 0.562 +boot: 0.554 +vnc: 0.440 + +virtio-scsi virtio-scsi-single and virtio-blk on raw image, games are not starting + +Using virtio-scsi / vitro-scsi-sing and vitro-blk on a ZFS/raw image, most Assassin's Creed (Origin especially) games are not starting (uPlay), it seems related to some check or commands applications are doing on the disk drive that fails to respond. + +Workaround has been found by creating a VHD volume, mounting it and installing games on it. + +On a side note, application like HDDScan, CrystalDiskInfo returns nothing regarding disk drives. + +Guest: +Windows 10 (build 1709) + +Host: +$ kvm --version +QEMU emulator version 2.9.1 pve-qemu-kvm_2.9.1-9 +$ uname -a +Linux xxxx 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64 GNU/Linux + +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/105/KVM/1758819 b/results/classifier/105/KVM/1758819 new file mode 100644 index 00000000..b9b63520 --- /dev/null +++ b/results/classifier/105/KVM/1758819 @@ -0,0 +1,351 @@ +KVM: 0.655 +instruction: 0.613 +device: 0.564 +graphic: 0.523 +semantic: 0.508 +mistranslation: 0.507 +boot: 0.502 +other: 0.477 +vnc: 0.469 +assembly: 0.417 +network: 0.389 +socket: 0.382 + +HVF Illegal instruction: 4, High Sierra, v2.12-rc0 + +I've built v2.12.0-rc0 on MacOS using homebrew. I'm running 10.13.3 on a 5,1 Mac Pro with a X5690 processor. + +When I run 'qemu-system-x86_64 -M accel=hvf', I get a crash "Illegal instruction: 4". + +Process: qemu-system-x86_64 [6330] +Path: /Users/USER/*/qemu-system-x86_64 +Identifier: qemu-system-x86_64 +Version: 0 +Code Type: X86-64 (Native) +Parent Process: bash [1558] +Responsible: qemu-system-x86_64 [6330] +User ID: 501 + +Date/Time: 2018-03-31 13:46:58.355 -0700 +OS Version: Mac OS X 10.13.4 (17E199) +Report Version: 12 +Anonymous UUID: 28693BB0-7F66-6066-026C-DDE857D912F6 + + +Time Awake Since Boot: 1800 seconds + +System Integrity Protection: disabled + +Crashed Thread: 0 Dispatch queue: com.apple.main-thread + +Exception Type: EXC_BAD_INSTRUCTION (SIGILL) +Exception Codes: 0x0000000000000001, 0x0000000000000000 +Exception Note: EXC_CORPSE_NOTIFY + +Termination Signal: Illegal instruction: 4 +Termination Reason: Namespace SIGNAL, Code 0x4 +Terminating Process: exc handler [0] + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 qemu-system-x86_64 0x000000010d8acafc hvf_get_supported_cpuid + 300 (x86_cpuid.c:102) +1 qemu-system-x86_64 0x000000010d8453e8 x86_cpu_expand_features + 200 (cpu.c:2408) +2 qemu-system-x86_64 0x000000010d847770 x86_cpu_realizefn + 288 (cpu.c:3669) +3 qemu-system-x86_64 0x000000010d92fa73 device_set_realized + 899 (qdev.c:917) +4 qemu-system-x86_64 0x000000010da6e123 property_set_bool + 99 +5 qemu-system-x86_64 0x000000010da6f410 object_property_set_qobject + 48 (qom-qobject.c:28) +6 qemu-system-x86_64 0x000000010da6ca71 object_property_set_bool + 49 (qobject.h:81) +7 qemu-system-x86_64 0x000000010d824baf pc_cpus_init + 415 (pc.c:1104) +8 qemu-system-x86_64 0x000000010d829c6d pc_init1 + 349 (pc_piix.c:157) +9 qemu-system-x86_64 0x000000010d8cb234 qemu_main + 17476 (vl.c:1275) +10 qemu-system-x86_64 0x000000010da6723e -[QemuCocoaAppController startEmulationWithArgc:argv:] + 30 (cocoa.m:1017) +11 com.apple.CoreFoundation 0x00007fff5294561c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 +12 com.apple.CoreFoundation 0x00007fff529454ea _CFXRegistrationPost + 458 +13 com.apple.CoreFoundation 0x00007fff52945221 ___CFXNotificationPost_block_invoke + 225 +14 com.apple.CoreFoundation 0x00007fff52903d72 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1826 +15 com.apple.CoreFoundation 0x00007fff52902e03 _CFXNotificationPost + 659 +16 com.apple.Foundation 0x00007fff54a1f8c7 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 +17 com.apple.AppKit 0x00007fff4fff3206 -[NSApplication _postDidFinishNotification] + 313 +18 com.apple.AppKit 0x00007fff4fff2e4f -[NSApplication _sendFinishLaunchingNotification] + 220 +19 com.apple.AppKit 0x00007fff4fec5ab3 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 562 +20 com.apple.AppKit 0x00007fff4fec56e9 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 690 +21 com.apple.Foundation 0x00007fff54a62714 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 287 +22 com.apple.Foundation 0x00007fff54a62592 _NSAppleEventManagerGenericHandler + 102 +23 com.apple.AE 0x00007fff53a3bdd0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788 +24 com.apple.AE 0x00007fff53a3b677 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41 +25 com.apple.AE 0x00007fff53a3b565 aeProcessAppleEvent + 383 +26 com.apple.HIToolbox 0x00007fff51c1d4a0 AEProcessAppleEvent + 55 +27 com.apple.AppKit 0x00007fff4fec0d32 _DPSNextEvent + 2788 +28 com.apple.AppKit 0x00007fff50656e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 +29 com.apple.AppKit 0x00007fff4feb5885 -[NSApplication run] + 764 +30 qemu-system-x86_64 0x000000010da68e99 main + 2537 (cocoa.m:1462) +31 libdyld.dylib 0x00007fff7ace7015 start + 1 + +Thread 1: +0 libsystem_kernel.dylib 0x00007fff7ae37d8a __semwait_signal + 10 +1 libsystem_c.dylib 0x00007fff7adb2724 nanosleep + 199 +2 libglib-2.0.0.dylib 0x000000010e8fc9fe g_usleep + 71 +3 qemu-system-x86_64 0x000000010db55f39 call_rcu_thread + 217 (rcu.c:244) +4 libsystem_pthread.dylib 0x00007fff7afff661 _pthread_body + 340 +5 libsystem_pthread.dylib 0x00007fff7afff50d _pthread_start + 377 +6 libsystem_pthread.dylib 0x00007fff7affebf9 thread_start + 13 + +Thread 2:: Dispatch queue: NSCGSDisableUpdates +0 libsystem_kernel.dylib 0x00007fff7ae2e20a mach_msg_trap + 10 +1 libsystem_kernel.dylib 0x00007fff7ae2d724 mach_msg + 60 +2 com.apple.SkyLight 0x00007fff74b129f5 CGSUpdateManager::enable_updates_common() + 565 +3 com.apple.SkyLight 0x00007fff74ab6b28 CGSUpdateManager::enable_update(unsigned long long) + 320 +4 libdispatch.dylib 0x00007fff7acb564a _dispatch_call_block_and_release + 12 +5 libdispatch.dylib 0x00007fff7acade08 _dispatch_client_callout + 8 +6 libdispatch.dylib 0x00007fff7acc2267 _dispatch_queue_serial_drain + 635 +7 libdispatch.dylib 0x00007fff7acb51b6 _dispatch_queue_invoke + 373 +8 libdispatch.dylib 0x00007fff7acc2f5d _dispatch_root_queue_drain_deferred_wlh + 332 +9 libdispatch.dylib 0x00007fff7acc6d71 _dispatch_workloop_worker_thread + 880 +10 libsystem_pthread.dylib 0x00007fff7affefd2 _pthread_wqthread + 980 +11 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 3: +0 libsystem_kernel.dylib 0x00007fff7ae38292 __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff7afff009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 4: +0 libsystem_kernel.dylib 0x00007fff7ae38292 __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff7afff009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 5: +0 libsystem_kernel.dylib 0x00007fff7ae38292 __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff7afff009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 6: +0 libsystem_kernel.dylib 0x00007fff7ae38042 __sigwait + 10 +1 libsystem_pthread.dylib 0x00007fff7b001ad9 sigwait + 61 +2 qemu-system-x86_64 0x000000010db4061b sigwait_compat + 59 (compatfd.c:37) +3 libsystem_pthread.dylib 0x00007fff7afff661 _pthread_body + 340 +4 libsystem_pthread.dylib 0x00007fff7afff50d _pthread_start + 377 +5 libsystem_pthread.dylib 0x00007fff7affebf9 thread_start + 13 + +Thread 0 crashed with X86 Thread State (64-bit): + rax: 0x000000010d8acae7 rbx: 0x000000000000000d rcx: 0x0000000000000000 rdx: 0x0000000000000002 + rdi: 0x000000000000000d rsi: 0x0000000000000000 rbp: 0x00007ffee246eed0 rsp: 0x00007ffee246ee80 + r8: 0x00007ffee246ee8c r9: 0x00007ffee246ee88 r10: 0x00007ffee246ee90 r11: 0x00007ffee246ee94 + r12: 0x0000000000000000 r13: 0x00007f875509b201 r14: 0x0000000000000000 r15: 0x0000000000000000 + rip: 0x000000010d8acafc rfl: 0x0000000000010246 cr2: 0x000000010d847650 + +Logical CPU: 2 +Error Code: 0x00000000 +Trap Number: 6 + + +Disregard the above log; that was from a September 2017 build. + +On RC1: + +Process: qemu-system-x86_64 [6567] +Path: /usr/local/bin/qemu-system-x86_64 +Identifier: qemu-system-x86_64 +Version: 0 +Code Type: X86-64 (Native) +Parent Process: bash [1558] +Responsible: qemu-system-x86_64 [6567] +User ID: 501 + +Date/Time: 2018-03-31 13:53:57.851 -0700 +OS Version: Mac OS X 10.13.4 (17E199) +Report Version: 12 +Anonymous UUID: 28693BB0-7F66-6066-026C-DDE857D912F6 + + +Time Awake Since Boot: 2200 seconds + +System Integrity Protection: disabled + +Crashed Thread: 0 Dispatch queue: com.apple.main-thread + +Exception Type: EXC_BAD_INSTRUCTION (SIGILL) +Exception Codes: 0x0000000000000001, 0x0000000000000000 +Exception Note: EXC_CORPSE_NOTIFY + +Termination Signal: Illegal instruction: 4 +Termination Reason: Namespace SIGNAL, Code 0x4 +Terminating Process: exc handler [0] + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 qemu-system-x86_64 0x000000010524165b 0x105134000 + 1103451 +1 qemu-system-x86_64 0x00000001051e2481 0x105134000 + 713857 +2 qemu-system-x86_64 0x00000001051e2170 0x105134000 + 713072 +3 qemu-system-x86_64 0x00000001051e3e2a 0x105134000 + 720426 +4 qemu-system-x86_64 0x00000001052b625a 0x105134000 + 1581658 +5 qemu-system-x86_64 0x00000001053e5606 0x105134000 + 2823686 +6 qemu-system-x86_64 0x00000001053e65bb 0x105134000 + 2827707 +7 qemu-system-x86_64 0x00000001053e4126 0x105134000 + 2818342 +8 qemu-system-x86_64 0x00000001051c35fc 0x105134000 + 587260 +9 qemu-system-x86_64 0x00000001051c36e6 0x105134000 + 587494 +10 qemu-system-x86_64 0x00000001051c8040 0x105134000 + 606272 +11 qemu-system-x86_64 0x000000010525a462 0x105134000 + 1205346 +12 qemu-system-x86_64 0x00000001053c8e28 0x105134000 + 2706984 +13 com.apple.CoreFoundation 0x00007fff5294561c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 +14 com.apple.CoreFoundation 0x00007fff529454ea _CFXRegistrationPost + 458 +15 com.apple.CoreFoundation 0x00007fff52945221 ___CFXNotificationPost_block_invoke + 225 +16 com.apple.CoreFoundation 0x00007fff52903d72 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1826 +17 com.apple.CoreFoundation 0x00007fff52902e03 _CFXNotificationPost + 659 +18 com.apple.Foundation 0x00007fff54a1f8c7 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 +19 com.apple.AppKit 0x00007fff4fff3206 -[NSApplication _postDidFinishNotification] + 313 +20 com.apple.AppKit 0x00007fff4fff2e4f -[NSApplication _sendFinishLaunchingNotification] + 220 +21 com.apple.AppKit 0x00007fff4fec5ab3 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 562 +22 com.apple.AppKit 0x00007fff4fec56e9 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 690 +23 com.apple.Foundation 0x00007fff54a62714 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 287 +24 com.apple.Foundation 0x00007fff54a62592 _NSAppleEventManagerGenericHandler + 102 +25 com.apple.AE 0x00007fff53a3bdd0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788 +26 com.apple.AE 0x00007fff53a3b677 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41 +27 com.apple.AE 0x00007fff53a3b565 aeProcessAppleEvent + 383 +28 com.apple.HIToolbox 0x00007fff51c1d4a0 AEProcessAppleEvent + 55 +29 com.apple.AppKit 0x00007fff4fec0d32 _DPSNextEvent + 2788 +30 com.apple.AppKit 0x00007fff50656e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 +31 com.apple.AppKit 0x00007fff4feb5885 -[NSApplication run] + 764 +32 qemu-system-x86_64 0x00000001053ca853 0x105134000 + 2713683 +33 libdyld.dylib 0x00007fff7ace7015 start + 1 + +Thread 1: +0 libsystem_kernel.dylib 0x00007fff7ae37a1e __psynch_cvwait + 10 +1 libsystem_pthread.dylib 0x00007fff7b000589 _pthread_cond_wait + 732 +2 qemu-system-x86_64 0x00000001054b0b27 0x105134000 + 3656487 +3 qemu-system-x86_64 0x00000001054bf128 0x105134000 + 3715368 +4 libsystem_pthread.dylib 0x00007fff7afff661 _pthread_body + 340 +5 libsystem_pthread.dylib 0x00007fff7afff50d _pthread_start + 377 +6 libsystem_pthread.dylib 0x00007fff7affebf9 thread_start + 13 + +Thread 2: +0 libsystem_kernel.dylib 0x00007fff7ae38292 __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff7afff009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 3:: Dispatch queue: NSCGSDisableUpdates +0 libsystem_kernel.dylib 0x00007fff7ae2e20a mach_msg_trap + 10 +1 libsystem_kernel.dylib 0x00007fff7ae2d724 mach_msg + 60 +2 com.apple.SkyLight 0x00007fff74b129f5 CGSUpdateManager::enable_updates_common() + 565 +3 com.apple.SkyLight 0x00007fff74ab6b28 CGSUpdateManager::enable_update(unsigned long long) + 320 +4 libdispatch.dylib 0x00007fff7acb564a _dispatch_call_block_and_release + 12 +5 libdispatch.dylib 0x00007fff7acade08 _dispatch_client_callout + 8 +6 libdispatch.dylib 0x00007fff7acc2267 _dispatch_queue_serial_drain + 635 +7 libdispatch.dylib 0x00007fff7acb51b6 _dispatch_queue_invoke + 373 +8 libdispatch.dylib 0x00007fff7acc2f5d _dispatch_root_queue_drain_deferred_wlh + 332 +9 libdispatch.dylib 0x00007fff7acc6d71 _dispatch_workloop_worker_thread + 880 +10 libsystem_pthread.dylib 0x00007fff7affefd2 _pthread_wqthread + 980 +11 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 4: +0 libsystem_pthread.dylib 0x00007fff7affebdc start_wqthread + 0 +1 ??? 0x000070000e958b50 0 + 123145546992464 + +Thread 5: +0 libsystem_kernel.dylib 0x00007fff7ae38292 __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff7afff009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff7affebe9 start_wqthread + 13 + +Thread 6: +0 libsystem_kernel.dylib 0x00007fff7ae38042 __sigwait + 10 +1 libsystem_pthread.dylib 0x00007fff7b001ad9 sigwait + 61 +2 qemu-system-x86_64 0x00000001054aee62 0x105134000 + 3649122 +3 libsystem_pthread.dylib 0x00007fff7afff661 _pthread_body + 340 +4 libsystem_pthread.dylib 0x00007fff7afff50d _pthread_start + 377 +5 libsystem_pthread.dylib 0x00007fff7affebf9 thread_start + 13 + +Thread 7: +0 libsystem_kernel.dylib 0x00007fff7ae37cfa __select + 10 +1 libglib-2.0.0.dylib 0x00000001061ebb60 g_poll + 430 +2 qemu-system-x86_64 0x00000001054ae80b 0x105134000 + 3647499 +3 qemu-system-x86_64 0x0000000105252eb2 0x105134000 + 1175218 +4 libsystem_pthread.dylib 0x00007fff7afff661 _pthread_body + 340 +5 libsystem_pthread.dylib 0x00007fff7afff50d _pthread_start + 377 +6 libsystem_pthread.dylib 0x00007fff7affebf9 thread_start + 13 + +Thread 0 crashed with X86 Thread State (64-bit): + rax: 0x0000000000000001 rbx: 0x000000000000000d rcx: 0x0000000000000000 rdx: 0x0000000000000000 + rdi: 0x000000000000000d rsi: 0x0000000000000000 rbp: 0x00007ffeeaac9f40 rsp: 0x00007ffeeaac9f00 + r8: 0x00007ffeeaac9f04 r9: 0x00007ffeeaac9f00 r10: 0x00007ffeeaac9f08 r11: 0x00007ffeeaac9f0c + r12: 0x0000000000000000 r13: 0x00007fe43f0af400 r14: 0x0000000000000000 r15: 0x0000000000000000 + rip: 0x000000010524165b rfl: 0x0000000000010246 cr2: 0x000000010518235d + +Logical CPU: 0 +Error Code: 0x00000000 +Trap Number: 6 + + +I am also able to reproduce this bug. The problem is that when hvf is enabled, qemu will attempt to execute the xgetbv instruction, which isn't supported on my processor (Intel Xeon X5670). + +Here is a stack trace from lldb; the behavior is 100% reproducible for me. + +nathan@Nathans-Mac-Pro:~/src/qemu/qemu-3.0.0/x86_64-softmmu +$ lldb -- qemu-system-x86_64 --accel hvf +(lldb) target create "qemu-system-x86_64" +runCurrent executable set to 'qemu-system-x86_64' (x86_64). +(lldb) settings set -- target.run-args "--accel" "hvf" +(lldb) run +Process 27479 launched: '/Users/nathan/src/qemu/qemu-3.0.0/x86_64-softmmu/qemu-system-x86_64' (x86_64) +Process 27479 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) + frame #0: 0x00000001001bca3a qemu-system-x86_64`xgetbv(xcr=0) at x86_cpuid.c:34 + 31 { + 32 uint32_t eax, edx; + 33 +-> 34 __asm__ volatile ("xgetbv" + 35 : "=a" (eax), "=d" (edx) + 36 : "c" (xcr)); + 37 +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) + * frame #0: 0x00000001001bca3a qemu-system-x86_64`xgetbv(xcr=0) at x86_cpuid.c:34 + frame #1: 0x00000001001bc8a6 qemu-system-x86_64`hvf_get_supported_cpuid(func=13, idx=0, reg=0) at x86_cpuid.c:116 + frame #2: 0x0000000100143a21 qemu-system-x86_64`x86_cpu_get_supported_feature_word(w=FEAT_XSAVE_COMP_LO, migratable_only=false) at cpu.c:3498 + frame #3: 0x000000010014367d qemu-system-x86_64`x86_cpu_filter_features(cpu=0x00000001040a2c00) at cpu.c:4749 + frame #4: 0x0000000100146c65 qemu-system-x86_64`x86_cpu_realizefn(dev=0x00000001040a2c00, errp=0x00007ffeefbfd620) at cpu.c:4834 + frame #5: 0x000000010028a84b qemu-system-x86_64`device_set_realized(obj=0x00000001040a2c00, value=true, errp=0x00007ffeefbfd7d0) at qdev.c:826 + frame #6: 0x00000001004b6d4d qemu-system-x86_64`property_set_bool(obj=0x00000001040a2c00, v=0x0000000101c49a20, name="realized", opaque=0x0000000101a996d0, errp=0x00007ffeefbfd7d0) at object.c:1984 + frame #7: 0x00000001004b4ae8 qemu-system-x86_64`object_property_set(obj=0x00000001040a2c00, v=0x0000000101c49a20, name="realized", errp=0x00007ffeefbfd7d0) at object.c:1176 + frame #8: 0x00000001004b8e8a qemu-system-x86_64`object_property_set_qobject(obj=0x00000001040a2c00, value=0x0000000101c49a00, name="realized", errp=0x00007ffeefbfd7d0) at qom-qobject.c:27 + frame #9: 0x00000001004b5092 qemu-system-x86_64`object_property_set_bool(obj=0x00000001040a2c00, value=true, name="realized", errp=0x00007ffeefbfd7d0) at object.c:1242 + frame #10: 0x000000010010ae20 qemu-system-x86_64`pc_new_cpu(typename="qemu64-x86_64-cpu", apic_id=0, errp=0x0000000100c44de0) at pc.c:1107 + frame #11: 0x000000010010af4c qemu-system-x86_64`pc_cpus_init(pcms=0x0000000101d630b0) at pc.c:1155 + frame #12: 0x000000010011294e qemu-system-x86_64`pc_init1(machine=0x0000000101d630b0, host_type="i440FX-pcihost", pci_type="i440FX") at pc_piix.c:153 + frame #13: 0x0000000100112640 qemu-system-x86_64`pc_init_v3_0(machine=0x0000000101d630b0) at pc_piix.c:438 + frame #14: 0x0000000100291f25 qemu-system-x86_64`machine_run_board_init(machine=0x0000000101d630b0) at machine.c:830 + frame #15: 0x00000001001e583f qemu-system-x86_64`qemu_main(argc=3, argv=0x00007ffeefbff818, envp=0x00007ffeefbff838) at vl.c:4516 + frame #16: 0x0000000100486459 qemu-system-x86_64`-[QemuCocoaAppController startEmulationWithArgc:argv:](self=0x0000000101c16510, _cmd="startEmulationWithArgc:argv:", argc=3, argv=0x00007ffeefbff818) at cocoa.m:1093 + frame #17: 0x00000001004862f7 qemu-system-x86_64`-[QemuCocoaAppController applicationDidFinishLaunching:](self=0x0000000101c16510, _cmd="applicationDidFinishLaunching:", note=@"NSApplicationDidFinishLaunchingNotification") at cocoa.m:1045 + frame #18: 0x00007fff4c99447c CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 + frame #19: 0x00007fff4c99434a CoreFoundation`_CFXRegistrationPost + 458 + frame #20: 0x00007fff4c994081 CoreFoundation`___CFXNotificationPost_block_invoke + 225 + frame #21: 0x00007fff4c952c12 CoreFoundation`-[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1826 + frame #22: 0x00007fff4c951ca3 CoreFoundation`_CFXNotificationPost + 659 + frame #23: 0x00007fff4ea7c817 Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 66 + frame #24: 0x00007fff4a041206 AppKit`-[NSApplication _postDidFinishNotification] + 313 + frame #25: 0x00007fff4a040e4f AppKit`-[NSApplication _sendFinishLaunchingNotification] + 220 + frame #26: 0x00007fff49f13ab3 AppKit`-[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 562 + frame #27: 0x00007fff49f136e9 AppKit`-[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 690 + frame #28: 0x00007fff4eabf664 Foundation`-[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 287 + frame #29: 0x00007fff4eabf4e2 Foundation`_NSAppleEventManagerGenericHandler + 102 + frame #30: 0x00007fff4da97dd0 AE`aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788 + frame #31: 0x00007fff4da97677 AE`dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41 + frame #32: 0x00007fff4da97565 AE`aeProcessAppleEvent + 383 + frame #33: 0x00007fff4bc6e4a0 HIToolbox`AEProcessAppleEvent + 55 + frame #34: 0x00007fff49f0ed32 AppKit`_DPSNextEvent + 2788 + frame #35: 0x00007fff4a6a4e34 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 + frame #36: 0x00007fff49f03885 AppKit`-[NSApplication run] + 764 + frame #37: 0x0000000100489161 qemu-system-x86_64`main(argc=3, argv=0x00007ffeefbff818) at cocoa.m:1537 + frame #38: 0x00007fff7493e015 libdyld.dylib`start + 1 + frame #39: 0x00007fff7493e015 libdyld.dylib`start + 1 +(lldb) p xcr +(uint32_t) $0 = 0 + +According to the response here: https://<email address hidden>/msg572220.html + +...the call to xgetbv should be guarded against processors that don't support the instruction. The attached patch seems to work for me but must admit I am way out of my depth here (I understand nothing about cpu architecture, features, etc...) and have not tested on anything but my old MacBook Pro (15-inch, Mid 2010) / MacBookPro6,2. All that I can say is that for this machine the call to xgetbv is not made and everything seems to work. I have no idea if this is correct for other machines/processors or if it correctly detects support of this call... + +Looking through old bug tickets ... Did you ever send your patch to the qemu-devel mailing list? See https://wiki.qemu.org/Contribute/SubmitAPatch for more information + +Looks like this should have been fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/118f2aadbc66aaae4e8d52 + diff --git a/results/classifier/105/KVM/1769189 b/results/classifier/105/KVM/1769189 new file mode 100644 index 00000000..01185b2f --- /dev/null +++ b/results/classifier/105/KVM/1769189 @@ -0,0 +1,142 @@ +KVM: 0.892 +other: 0.877 +device: 0.867 +instruction: 0.863 +boot: 0.861 +vnc: 0.859 +mistranslation: 0.856 +semantic: 0.832 +assembly: 0.824 +network: 0.792 +graphic: 0.791 +socket: 0.700 + +Issue with qemu 2.12.0 + SATA + +(first reported here: https://bugzilla.tianocore.org/show_bug.cgi?id=949 ) + +I had a Windows 10 VM running perfectly fine with OVMF UEFI, since I upgraded to qemu 2.12, the guests hangs for a couple of minutes, works for a few seconds, and hangs again, etc. By "hang" I mean it doesn't freeze, but it looks like it's waiting on IO or something, I can move the mouse but everything needing disk access is unresponsive. + +What doesn't work: qemu 2.12 with OVMF +What works: using BIOS or downgrading qemu to 2.11.1. + +Platform is arch linux 4.16.7 on skylake, I have attached the vm xml file. + + + +I'm seeing the same Win10 I/O stall problem with qemu 2.12, but with a vm with BIOS, not UEFI. +The solution for me is only dowgrading for now. + +I have the same issue. When I open the task manager on the virtualized Windows 10 VM I see the HDD time is at 100% but the data transfer rate is actual 0b/s. +I've tried any combination of the options below and the issue was always reproducible with qemu-2.12.0-1 and never with qemu-2.11.1-2. + +Linux kernels: +- 4.14.5-1 +- 4.16.7 + +Windows 10 Verson (for the VM) +- 1709 +- 1803 + +Boot HDD for VM +- Actual SSD (/dev/sda) +- QCOW2 Image + +QEMU +- qemu-2.11.1-2 +- qemu-2.12.0-1 + + +I also use ARCH Linux and have also downgraded to pre 2.12 QEMU + + +I have done some further tests and the problem seems to be SATA, not UEFI, I have updated the bug description to reflect this. + +François: Would it be possible for you to try a bisect build to try and figure out which change in qemu caused the problem? + + +For me it is hangs with SATA, but IDE is fine. + +Windows 7 Version (for the VM) +- SP1 + +Boot HDD for VM +- Actual HDD (/dev/sda) +- QCOW2 Image + +QEMU +- qemu-2.12.0-1 + +I've tried bisecting a few times, but since my reproducer wasn't reliable enough, I didn't identify the issue. (I see a bisect reported on qemu ML which seems like a bogus result, similar to mine). + +In my case, after the "hang", Windows 10 resets the ahci device after 2 minutes and it continues on until another hang happens. Seems fairly random. I increased the number of vcpu's assigned which seemed to increase the likelihood of the hang. + +I also went so far as to instrument an injection of the ahci interrupt via the monitor (total kludge, I know), and the guest did get out of the hung condition right away when I did that. + +I tried bisecting as well, and I wound up at: + +1a423896 -- five out of five boot attempts succeeded. +d759c951 -- five out of five boot attempts failed. + + + +d759c951f3287fad04210a52f2dc93f94cf58c7f is the first bad commit +commit d759c951f3287fad04210a52f2dc93f94cf58c7f +Author: Alex Bennée <email address hidden> +Date: Tue Feb 27 12:52:48 2018 +0300 + + replay: push replay_mutex_lock up the call tree + + + + +My methodology was to boot QEMU like this: + +./x86_64-softmmu/qemu-system-x86_64 -m 4096 -cpu host -M q35 -enable-kvm -smp 4 -drive id=sda,if=none,file=/home/bos/jhuston/windows_10.qcow -device ide-hd,drive=sda -qmp tcp::4444,server,nowait + +and run it three times with -snapshot and see if it hung during boot; if it did, I marked the commit bad. If it did not, I booted and attempted to log in and run CrystalDiskMark. If it froze before I even launched CDM, I marked it bad. + +Interestingly enough, on a subsequent (presumably bad) commit (6dc0f529) which hangs fairly reliably on bootup (66%) I can occasionally get into Windows 10 and run CDM -- and that unfortunately does not seem to trigger the error again, so CDM doesn't look like a reliable way to trigger the hangs. + + + + +Anyway, d759c951 definitely appears to change the odds of AHCI locking up during boot for me, and I suppose it might have something to do with how it is changing the BQL acquisition/release in main-loop.c, but I am not sure why/what yet. + +Before this patch, we only lock the iothread and re-lock it if there was a timeout, and after this patch we *always* lock and unlock the iothread. This is probably just exposing some latent bug in the AHCI emulator that has always existed, but now the odds of seeing it are much higher. + +I'll have to dig as to what the race is -- I'm not sure just yet. + + +If those of you who are seeing this bug too could confirm for me that d759c951 appears to be the guilty party, that probably wouldn't hurt. + +Thanks! +--js + +I can confirm that for me commit d759c951 does cause / expose the issue. + +There might be multiple issues present and I'm having difficulty reliably doing any kind of regression testing here, but I think this patch helps fix at least one of the issues I was seeing that occurs specifically during early boot. It may fix other hangs. + + + +Oughtta be fixed in current master, will be fixed in 2.12.1 and 3.0. + +Hi, Where can I find the fix patch at present? + +5694c7eacce6b263ad7497cc1bb76aad746cfd4e ahci: fix PxCI register race + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5694c7eacce6b263ad7497cc1bb76aad746cfd4e + +Could this affect virtio-scsi? I'm not so sure since it's not perfectly reliable to reproduce, but v2.12.0 was hanging for me for a few minutes at a time with virtio-scsi cache=writeback showing 100% disk util%. I never had issues booting up, and didn't try SATA. v2.11.1 was fine. + +My first attempt to bisect didn't turn out right... had some false positives I guess. The 2nd attempt (telling git the bads from first try) got to 89e46eb477113550485bc24264d249de9fd1260a as latest good (which is 4 commits *after* the bisect by John Snow) and 7273db9d28d5e1b7a6c202a5054861c1f0bcc446 as bad. + +But testing with this patch, it seems to work (or false positive still... after a bunch of usage). And so I didn't finish the bisect. + +The fix posted exclusively changes the behavior of AHCI devices; however the locking changes that jostled the AHCI bug loose could in theory jostle loose some bugs in other devices, too. + +I don't think it is possible that the fix for AHCI would have any impact on virtio-scsi devices. + +If you're seeing issues in virtio-scsi, I'd make a new writeup in a new LP. +--js + diff --git a/results/classifier/105/KVM/1770724 b/results/classifier/105/KVM/1770724 new file mode 100644 index 00000000..2b15883e --- /dev/null +++ b/results/classifier/105/KVM/1770724 @@ -0,0 +1,93 @@ +KVM: 0.790 +mistranslation: 0.681 +vnc: 0.637 +other: 0.598 +boot: 0.587 +device: 0.586 +network: 0.582 +instruction: 0.569 +graphic: 0.568 +semantic: 0.559 +assembly: 0.547 +socket: 0.538 + +e1000 takes a long time (2 seconds) to set link ready + +When a VM is booted with e1000 NIC, it takes a long time (2 seconds) for the guest to bring up the link. This can be seen in the following dmesg messages: + +[ 4.899773] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready +[ 6.889165] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX +[ 6.891372] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready + +The first message happens when the guest calls to ifup eth0; ifup does not hold control until the link is established. The guest I am using (cirros 0.4.0) then starts udhcpc DHCP client that issues a DHCP request, then waits for 60 seconds for reply, then repeats the DHCP request. When the first request is sent, the link is not ready yet, so the frame is lost; when the second request is sent, the link is up and DHCP lease is received. + +If I use different NICs (e1000e, virtio, rtl*), there are no dmesg messages, and the very first DHCP request correctly reaches outside and results in a lease acquired. + +The qemu version I am using is 2.10.1 from Fedora 27. I tried to reproduce with runtime from Fedora 29 that includes 2.12 but I have different issues there that block me from reproducing the original issue (there, I get kernel traces, irq interrupt errors, and no network link at all). + +For the record, the qemu in question is started by kubevirt inside a docker container with Fedora 27 based image. + +=============================== + +The command line of qemu is as follows: + +27404 ? Sl 0:10 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=default_ovm-cirros,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_ovm-cirros/master-key.aes -machine pc-q35-2.10,accel=kvm,usb=off,dump-guest-core=off -m 62 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 8769fdbe-d957-5567-bd71-114ba0eb4811 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-default_ovm-cirros/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x4 -device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive file=/var/run/libvirt/kubevirt-ephemeral-disk/registry-disk-data/default/ovm-cirros/disk_registryvolume/disk-image.raw,format=raw,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/run/libvirt/kubevirt-ephemeral-disk/cloud-init-data/default/ovm-cirros/noCloud.iso,format=raw,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=0a:58:0a:f4:01:e1,bus=pci.2,addr=0x1 -chardev socket,id=charserial0,path=/var/run/kubevirt-private/default/ovm-cirros/virt-serial0,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -vnc vnc=unix:/var/run/kubevirt-private/default/ovm-cirros/virt-vnc -device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 -device virtio-balloon-pci,id=balloon0,bus=pci.6,addr=0x0 -msg timestamp=on + +============================ + +Hypervisor versions of interest: + +[vagrant@node02 ~]$ sudo docker exec -it $(sudo docker ps | grep virt-launcher-ovm-cirros | grep entrypoint | awk -e '{print $1}') rpm -qa | grep 'qemu\|libvirt' +qemu-block-curl-2.10.1-2.fc27.x86_64 +qemu-block-ssh-2.10.1-2.fc27.x86_64 +qemu-block-nfs-2.10.1-2.fc27.x86_64 +qemu-system-x86-core-2.10.1-2.fc27.x86_64 +libvirt-daemon-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-disk-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-mpath-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-zfs-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-nwfilter-3.7.0-4.fc27.x86_64 +qemu-img-2.10.1-2.fc27.x86_64 +qemu-common-2.10.1-2.fc27.x86_64 +qemu-block-dmg-2.10.1-2.fc27.x86_64 +qemu-block-rbd-2.10.1-2.fc27.x86_64 +qemu-system-x86-2.10.1-2.fc27.x86_64 +libvirt-libs-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-core-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-qemu-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-gluster-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-logical-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-rbd-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-sheepdog-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-nodedev-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-secret-3.7.0-4.fc27.x86_64 +libvirt-client-3.7.0-4.fc27.x86_64 +ipxe-roms-qemu-20161108-2.gitb991c67.fc26.noarch +qemu-block-gluster-2.10.1-2.fc27.x86_64 +qemu-block-iscsi-2.10.1-2.fc27.x86_64 +qemu-kvm-2.10.1-2.fc27.x86_64 +libvirt-daemon-driver-network-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-iscsi-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-scsi-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-interface-3.7.0-4.fc27.x86_64 +libvirt-daemon-kvm-3.7.0-4.fc27.x86_64 + +[vagrant@node02 ~]$ uname -a +Linux node02 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +[vagrant@node02 ~]$ cat /etc/redhat-release +CentOS Linux release 7.4.1708 (Core) + +============================= + +Guest: + +$ uname -a +Linux ovm-cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux + +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/105/KVM/1775702 b/results/classifier/105/KVM/1775702 new file mode 100644 index 00000000..d5f3ea37 --- /dev/null +++ b/results/classifier/105/KVM/1775702 @@ -0,0 +1,96 @@ +KVM: 0.814 +vnc: 0.672 +mistranslation: 0.664 +device: 0.564 +network: 0.544 +instruction: 0.543 +assembly: 0.542 +other: 0.542 +semantic: 0.541 +graphic: 0.516 +boot: 0.513 +socket: 0.484 + +High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803 + +After upgrading Windows 10 guest to version 1803, guests VM runs slower and there is high host CPU load even when guest is almost idle. Did not happened with windows 10 up to version 1709. + +See my 1st report here: +https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803 + +Another user report is here: +https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/ + +Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu 2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three platform showing the same slowdown and higher host cpu load with windows 10 1803 VM compared to windows 10 1709 VM. + +This bug affect me + +I ran into similar issues with Windows 10 (1803), with regard to 2D graphics performance. + +See my bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=200877 + +Could you test with Spectre protection (temporarily) turned off inside the Windows VM? + +See my post here: https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/ + + + +Hi, +proxmox users have reported this bug +https://forum.proxmox.com/threads/high-cpu-load-for-windows-10-guests-when-idle.44531/#post-213876 + +hv_synic && hv_stimer hyperv enlightments fix it + + +(seem to be related to some hpet change in windows) + + + +----- Mail original ----- +De: "Lemos Lemosov" <email address hidden> +À: "qemu-devel" <email address hidden> +Envoyé: Mercredi 1 Août 2018 08:43:46 +Objet: [Qemu-devel] [Bug 1775702] Re: High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803 + +This bug affect me + +-- +You received this bug notification because you are a member of qemu- +devel-ml, which is subscribed to QEMU. +https://bugs.launchpad.net/bugs/1775702 + +Title: +High host CPU load and slower guest after upgrade guest OS Windows 10 +to ver 1803 + +Status in QEMU: +New + +Bug description: +After upgrading Windows 10 guest to version 1803, guests VM runs +slower and there is high host CPU load even when guest is almost idle. +Did not happened with windows 10 up to version 1709. + +See my 1st report here: +https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803 + +Another user report is here: +https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/ + +Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu +2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three +platform showing the same slowdown and higher host cpu load with +windows 10 1803 VM compared to windows 10 1709 VM. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1775702/+subscriptions + + + +hv_synic && hv_stimer only reduces the cpu from 40-50% to 4-5%. +still expecting under 1% like linux guests. + +I found that C:\Program Files (x86)\SPICE Guest Tools\drivers\Balloon\w10\amd64/blnsvr.exe intensively requesting something in WMI-provider-host. And there are a lot of errors in event logs about it also. + +Gannet, SPICE Guest Tools is certainly a different problem, you should report that to the spice project instead. And since the original problem was apparently fixed via hv_synic / hv_stimer (if I got the comments right), I'm closing this ticket now. + diff --git a/results/classifier/105/KVM/1776920 b/results/classifier/105/KVM/1776920 new file mode 100644 index 00000000..514cc43b --- /dev/null +++ b/results/classifier/105/KVM/1776920 @@ -0,0 +1,470 @@ +KVM: 0.678 +boot: 0.676 +instruction: 0.636 +device: 0.630 +vnc: 0.598 +other: 0.598 +graphic: 0.572 +semantic: 0.543 +assembly: 0.539 +socket: 0.485 +network: 0.438 +mistranslation: 0.337 + +qemu-img convert on Mac OSX creates corrupt images + +An image created by qemu-img create, then modified by another program is converted to bad/corrupt image when using convert sub command on Mac OSX. The same convert works on Linux. The version of qemu-img is 2.12. + +Can this be done with like a 1M example file that you could copy off in all stages. + +Provide the commands you use like +1. create +2. do ?? +3. convert + +Then for Mac and Linux you'd have M1/M2/M3 L1/L2/L3 files that can all be attached here to be evaluated for what might be broken. + +IMHO In the current state there is neither enough data for good debugging, not enough steps to reproduce what exactly you faced. + +I will provide all necessary info. Unfortunately the smallest image I can +provide is around 10M. + +What is M1/M2/M3 L1/L2/L3 file? + +Waldek + +On Thu, Jun 14, 2018 at 10:46 AM, Christian Ehrhardt < +<email address hidden>> wrote: + +> Can this be done with like a 1M example file that you could copy off in +> all stages. +> +> Provide the commands you use like +> 1. create +> 2. do ?? +> 3. convert +> +> Then for Mac and Linux you'd have M1/M2/M3 L1/L2/L3 files that can all +> be attached here to be evaluated for what might be broken. +> +> IMHO In the current state there is neither enough data for good +> debugging, not enough steps to reproduce what exactly you faced. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1776920 +> +> Title: +> qemu-img convert on Mac OSX creates corrupt images +> +> Status in QEMU: +> New +> +> Bug description: +> An image created by qemu-img create, then modified by another program +> is converted to bad/corrupt image when using convert sub command on +> Mac OSX. The same convert works on Linux. The version of qemu-img is +> 2.12. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1776920/+subscriptions +> + + +> +> I will provide all necessary info. Unfortunately the smallest image I can +> provide is around 10M. +> +> What is M1/M2/M3 L1/L2/L3 file? +> + +Just a suggestion how you could name the files +Linux-at-step-1 would be L1 and similar. + + +Are you converting to a destination on APFS? If yes, do you have the ability to easily reproduce this by converting to a non-APFS destination and seeing if that breaks too? + +Thanks, +--js + +I believe I have distilled entire process to few repeatable steps that can be fully reproduced on my Mac. The binary source files - - boot.bin and lzloader.elf - were created on my Linux VM running in VirtualBox on same Mac but I do not think it matters as the execution completely happens on Mac. + +The steps executed on my mac: +1. dd if=boot.bin of=image.img > /dev/null 2>&1 +2. dd if=lzloader.elf of=image.img conv=notrunc seek=128 > /dev/null 2>&1 +3. qemu-img convert image.img -O qcow2 image.qemu +4. qemu-img convert image.qemu -O qcow2 image2.qemu + +The end result: +ll image* +-rw-r--r-- 1 *** *** 6684672 Jun 14 17:17 image.img +-rw-r--r-- 1 *** *** 7012352 Jun 14 17:40 image.qemu +-rw-r--r-- 1 *** *** 196616 Jun 14 17:40 image2.qemu + +The result of regular compare: +qemu-img compare image.qemu image2.qemu +Images are identical. + +The result of strict compare: +qemu-img compare -s image.qemu image2.qemu +Strict mode: Offset 0 block status mismatch! + +Images are clearly different. + +The same 4 steps executed on my Linux VM behave correctly - image.qemu is TRULY identical with image2.qemu. + +Qemu-img on my Mac: +qemu-img --version +qemu-img version 2.12.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Details about Mac and OSX version: +Model Name: MacBook Pro + Model Identifier: MacBookPro13,3 + Processor Name: Intel Core i7 + Processor Speed: 2.7 GHz + Number of Processors: 1 + Total Number of Cores: 4 + L2 Cache (per Core): 256 KB + L3 Cache: 8 MB + Memory: 16 GB + +Mac filesystem: +Mount Point: / + File System: APFS + Writable: Yes + Ignore Ownership: No + BSD Name: disk1s1 + Physical Drive: + Device Name: APPLE SSD SM0512L + Media Name: AppleAPFSMedia + Medium Type: SSD + Protocol: PCI-Express + Internal: Yes + Partition Map Type: Unknown + +I am also attaching both source files and images for examination. + +Source file 1 + +Source file 2 + +Raw image created by dd in steps 1 and 2. + +Original qcow2 image converted from raw image in step 3. + +The corrupt qcow2 image created by converting image.qemu in step 4. + +Also if I use the same image.qemu file and convert to vmdk format I get even smaller file which for sure is wrong as well: + +qemu-img convert image.qemu -O vmdk image2.vbox + +ll image* +-rw-r--r-- 1 *** *** 6684672 Jun 14 17:17 image.img +-rw-r--r-- 1 *** *** 7012352 Jun 14 17:40 image.qemu +-rw-r--r-- 1 *** *** 196616 Jun 14 17:40 image2.qemu +-rw-r--r-- 1 *** *** 65536 Jun 14 18:00 image2.vbox + +Have I provided all necessary data and other details? + +I haven't had the time to look just yet. + +If there's a developer out there with a Mac has the bandwidth to take a look at this I'd be grateful. (I don't have access to one presently.) + +I see that the target filesystem is APFS however -- I think we might have a bug in our APFS support. Do you have the ability to try it on your Mac but on a non-APFS destination? + +It looks like the image is pretty small (~6MB?) so maybe you can try with a non-APFS formatted thumb drive? + +My hunch is that: +- APFS source to FAT32 destination might work correctly. +- FAT32 source to FAT32 destination will definitely work correctly. + +I have done more tests based on your suggestion and I think it is the opposite. The problem happens is the source is APFS. + +Following failed: +APFS -> ExFAT +APFS -> Fat32 + +Following worked: +ExFAT -> APFS +FAT32 -> APFS + +So for now my workaround is to use USB stick formatted with FAT32 or ExFAT, copy the source images there and then convert to somewhere or my main drive with APFS. + +My regards, +Waldek + +Sent from my iPhone + +> On Jun 20, 2018, at 11:54, John Snow <email address hidden> wrote: +> +> I haven't had the time to look just yet. +> +> If there's a developer out there with a Mac has the bandwidth to take a +> look at this I'd be grateful. (I don't have access to one presently.) +> +> I see that the target filesystem is APFS however -- I think we might +> have a bug in our APFS support. Do you have the ability to try it on +> your Mac but on a non-APFS destination? +> +> It looks like the image is pretty small (~6MB?) so maybe you can try +> with a non-APFS formatted thumb drive? +> +> My hunch is that: +> - APFS source to FAT32 destination might work correctly. +> - FAT32 source to FAT32 destination will definitely work correctly. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1776920 +> +> Title: +> qemu-img convert on Mac OSX creates corrupt images +> +> Status in QEMU: +> New +> +> Bug description: +> An image created by qemu-img create, then modified by another program +> is converted to bad/corrupt image when using convert sub command on +> Mac OSX. The same convert works on Linux. The version of qemu-img is +> 2.12. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1776920/+subscriptions + + +Great, thanks for the additional info! + +It sounds like maybe something to do with our sparse detection on APFS is broken. Maybe lseek calls are failing? This is a bad problem because it means that any read from an APFS source could break similarly. + +I'm still a bit tied down with other work at the moment, but I will try to address this prior to the 3.0 release if nobody else gets to it first. + +I am not familiar with QEMU source code but I might have some cycles to look into it. Where would I look - https://github.com/qemu/qemu/blob/master/qemu-img.c? Or somewhere else? Any suggestions would be appreciated. + +My hunch is that we're handling zero regions incorrectly and we might be skipping data regions we ought to be copying. + +...I'm looking at the `image2.qemu` file you've uploaded and it's empty! we didn't copy *anything* from your source file. + +Try converting with '-S 0` to disable sparse protection and see if that might help. + + '-S' indicates the consecutive number of bytes (defaults to 4k) that must + contain only zeros for qemu-img to create a sparse image during + conversion. If the number of bytes is 0, the source will not be scanned for + unallocated or zero sectors, and the destination image will always be + fully allocated + +If that helps, I'd take a look at img_convert in qemu-img.c ... + +convert_iteration_sectors looks relevant, it appears to help us know which sectors to copy when called by convert_co_do_copy. + +Tracing around "convert_co_read" in the same function might also help us to know which portions of the image we're even deciding to read; and we could probably track backwards from there to figure out which condition(s) are disqualifying us if we're deciding not to copy data. + +My current hunch is that bdrv_block_status[_above] is returning something wrong when backed by APFS. + +Bingo! Adding '-S 0' makes convert work. But it is not perfect as the end result is fully allocated image. + +So with qcow2 like this: + +image: mysql-example.qemu +file format: qcow2 +virtual size: 10G (10737418240 bytes) +disk size: 50M +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +and do this: + +qemu-img convert mysql-example.qemu -S 0 -O vmdk mysql-example.vbox + +I get 10G vmdk file: +10738794496 Jul 6 18:27 mysql-example.vbox + +I marked https://bugs.launchpad.net/qemu/+bug/1738840 as a duplicate of this bug, even though that bug was older, this bug has a slightly more active thread. + +I'm still in need of either an APFS capable machine that I can reproduce on, or another mac dev willing to help a bit, though. + + + +I have done some experiments and find out that +the behavior of lseek with whence set to SEEK_DATA is different from the behavior of Linux's lseek. + +If the supplied offset is in the middle of a data region, it returns the start of the next data region. There may be many data regions in a big file even though it has no hole. + +return value of lseek with whence set to SEEK_DATA: + +|--(offset)--Data----|(return value)----Data----| +|--(offset)--Data----|----Hole----|(return value)----Data----| + + +On 09/07/2018 01:04 PM, Yan-Jie Wang wrote: +> I have done some experiments and find out that +> the behavior of lseek with whence set to SEEK_DATA is different from the behavior of Linux's lseek. +> +> If the supplied offset is in the middle of a data region, it returns the +> start of the next data region. There may be many data regions in a big +> file even though it has no hole. +> +> return value of lseek with whence set to SEEK_DATA: +> +> |--(offset)--Data----|(return value)----Data----| +> |--(offset)--Data----|----Hole----|(return value)----Data----| +> +> +> ** Patch added: "macOS-lseek.patch" +> https://bugs.launchpad.net/qemu/+bug/1776920/+attachment/5186138/+files/macOS-lseek.patch + +While a developer can chase a URL, our CI tools can't. Can you please +also send that patch directly to <email address hidden>, so that it gets +the same level of review as other patches? + +But I am very reluctant to take your patch. MacOS is flat-out buggy and +in violation of the specification of lseek(SEEK_DATA), so making all +applications work around their bug is not going to scale as well as +having them fix their bug in the first place. + +Here's the proposed POSIX specification for what lseek(SEEK_DATA) is +supposed to do: +http://austingroupbugs.net/view.php?id=415#c862 + +That text has been present for 7 years now - so anyone implementing +SEEK_DATA should really be paying attention to interoperability with +that text. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +Hi, + +I recently ran into problems and after a long time trying to find out the cause landed here, I got in trouble using a CentOs Cloud image: +https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1905.qcow2.xz +which extracts to a .qcow2 image with sha256 of: +b376afdc0150601f15e53516327d9832216e01a300fecfc302066e36e2ac2b39 + +image: CentOS-7-x86_64-GenericCloud-1905.qcow2 +file format: qcow2 +virtual size: 8.0G (8589934592 bytes) +disk size: 898M +cluster_size: 65536 +Format specific information: + compat: 0.10 + refcount bits: 16 + +I use this command on a Mac, OS X 10.13.6 (17G7024), qemu installed via brew: +qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6=on -p CentOS-7-x86_64-GenericCloud-1905.qcow2 -S 0 result.vmdk + + +941359104 21 Jul 17:11 CentOS-7-x86_64-GenericCloud-1905.qcow2 - original image + +Converting this gives these results: +214551040 23 Jul 20:45 conv_mac_v3_1_mit_s_0.vmdk - doesnt work, made on Mac (APFS) with -S 0 +402303488 23 Jul 20:50 conv_mac_v3_1_auf_exfat.vmdk - works and is bootable, made on same Mac, on external drive, exFAT formatted. +149743104 23 Jul 21:21 conv_mac_v4_0.vmdk - doesnt work, made on Mac (APFS) without -S 0 +214551040 23 Jul 21:20 conv_mac_v4_0mit_S0.vmdk - doesnt work, made on Mac (APFS) with -S 0 + +converting on non-Mac also works fine: +402303488 23 Jul 18:48 conv_centos7_v1-5-3.vmdk - works and is bootable, made on Centos, qemu-img version 1.5.3 + +So it seems that '-S 0' didn't fix it for me, or is that only in the development branch? + +Best Regards + + + + +Hi, there isn't really a development branch; if '-S 0' didn't help alleviate the problem there may be other problems at hand, or the APFS implementation of SEEK_DATA is causing us even more problems in new versions. + +You could try Yan-Jie Wang's patch that was posted in #20, but until it's posted to the mailing list with a Signed-off-by tag, we can't include it ourselves. + +However, it would still be nice to know if it fixes your problem. + +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.] + +Hey there! I tested @wkozaczuk's suggested minimal steps and THEY WORKED FOR ME!! + +The steps executed on my mac: +1. dd if=boot.bin of=image.img > /dev/null 2>&1 +2. dd if=lzloader.elf of=image.img conv=notrunc seek=128 > /dev/null 2>&1 +3. qemu-img convert image.img -O qcow2 image.qemu +4. qemu-img convert image.qemu -O qcow2 image2.qemu + +The end result: +-rw-r--r-- 1 *** *** 6684672 Jun 22 14:19 image.img +-rw-r--r-- 1 *** *** 7012352 Jun 22 14:20 image.qemu +-rw-r--r-- 1 *** *** 7012352 Jun 22 14:20 image2.qemu +-rw-r--r-- 1 *** *** 6750208 Jun 22 14:22 image2.vbox + +The result of regular compare: +qemu-img compare image.qemu image2.qemu +Images are identical. + +The result of strict compare: +qemu-img compare -s image.qemu image2.qemu +Images are identical. + +Qemu-img on my Mac: +qemu-img --version +qemu-img version 6.0.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +Hardware Overview: + + Model Name: MacBook Pro + Model Identifier: MacBookPro16,1 + Processor Name: 8-Core Intel Core i9 + Processor Speed: 2,4 GHz + Number of Processors: 1 + Total Number of Cores: 8 + L2 Cache (per Core): 256 KB + L3 Cache: 16 MB + Hyper-Threading Technology: Enabled + Memory: 64 GB + Activation Lock Status: Enabled + +Storage: + + Mount Point: / + File System: APFS + Writable: No + Ignore Ownership: No + BSD Name: disk1s1 + Physical Drive: + Device Name: APPLE SSD AP1024N + Media Name: AppleAPFSMedia + Medium Type: SSD + Protocol: PCI-Express + Internal: Yes + Partition Map Type: Unknown + S.M.A.R.T. Status: Verified + +System Software Overview: + + System Version: macOS 10.15.7 (19H1217) + Kernel Version: Darwin 19.6.0 + Boot Volume: Macintosh HD + Boot Mode: Normal + Secure Virtual Memory: Enabled + System Integrity Protection: Enabled + + diff --git a/results/classifier/105/KVM/1778966 b/results/classifier/105/KVM/1778966 new file mode 100644 index 00000000..a807388a --- /dev/null +++ b/results/classifier/105/KVM/1778966 @@ -0,0 +1,49 @@ +KVM: 0.971 +boot: 0.938 +graphic: 0.878 +device: 0.847 +other: 0.842 +instruction: 0.820 +semantic: 0.676 +mistranslation: 0.636 +network: 0.578 +assembly: 0.410 +socket: 0.389 +vnc: 0.348 + +Windows 1803 and later crashes on KVM + +For a bionic host, using the current public kvm modules, KVM is not capable of booting a WindowsInsider or msdn Windows 1803 iso. In stallign from an ISO from a started windows 2016 guest results in an unbootable and unrepairable guest. + +The hardware is a threadripper 1920x with 32GB of main memory, disk mydigital BPX SSD and WD based 4 column RAID 5 via mdadm. + +This sounds like the same problem we're investigating in Fedora/RHEL land affecting guests with EPYC CPU, or host-passthrough from an EPYC family 17h host. Workaround should be to use "-cpu Opteron_G5" for now + +https://bugzilla.redhat.com/show_bug.cgi?id=1592276 +https://bugzilla.redhat.com/show_bug.cgi?id=1593190 + +Looks like windows is tickling an undocumented MSR and we're trying to find out what this MSR is supposed todo and thus how to handle it in KVM/QEMU + +That is very helpful. I'll try it. + +I standby to try a fix as soon as someone has one. + +Regrettably opteron_g5 is not a workaround. I get a complaint that my cpu doesn't provide xop, fma4, tbm. + +I've tried a number of other cpus including nehalem, phenom and athlon with similar results. + +Opteron didn't work do to some missing features. I was able to get nehalem to come up but that looks like the closest. + +Is there any way to define a new CPU model that isn't EPYC (maybe ryzen?) but is feature compatible with the threadripper? + +I ran into the same problem on threadripper 1900X. I was using cpu type "host-passthough" and it crashed. I fixed the crash by disabling the MSR with + +kvm.ignore_msrs=1 + +as describe in https://forum.level1techs.com/t/windows-10-1803-as-guest-with-qemu-kvm-bsod-under-install/127425/10 + +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/105/KVM/1788582 b/results/classifier/105/KVM/1788582 new file mode 100644 index 00000000..5fb13671 --- /dev/null +++ b/results/classifier/105/KVM/1788582 @@ -0,0 +1,87 @@ +KVM: 0.946 +device: 0.945 +mistranslation: 0.940 +graphic: 0.938 +boot: 0.935 +semantic: 0.931 +assembly: 0.927 +socket: 0.927 +instruction: 0.925 +vnc: 0.924 +other: 0.918 +network: 0.916 + +Race condition during shutdown + +I ran into a bug when I started several VMs in parallel using +libvirt. The VMs are using only a kernel and a initrd (which includes a +minimal OS). The guest OS itself does a 'poweroff -f' as soon as the +login prompt shows up. So the expectaction is that the VMs will start, +the shutdown will be initiated, and the QEMU processes will then +end. But instead some of the QEMU processes get stuck in ppoll(). + +A bisect showed that the first bad commit was +0f12264e7a41458179ad10276a7c33c72024861a ("block: Allow graph changes in +bdrv_drain_all_begin/end sections"). + +I've already tried the current master (13b7b188501d419a7d63c016e00065bcc693b7d4) +since the problem might be related +to the commit a1405acddeb0af6625dd9c30e8277b08e0885bd3 ("aio: Do +aio_notify_accept only during blocking aio_poll"). But the bug is still +there. I’ve reproduced the bug on x86_64 and on s390x. + +The backtrace of a hanging QEMU process: + +(gdb) bt +#0 0x00007f5d0e251b36 in ppoll () from target:/lib64/libc.so.6 +#1 0x0000560191052014 in qemu_poll_ns (fds=0x560193b23d60, nfds=5, timeout=55774838936000) at /home/user/git/qemu/util/qemu-timer.c:334 +#2 0x00005601910531fa in os_host_main_loop_wait (timeout=55774838936000) at /home/user/git/qemu/util/main-loop.c:233 +#3 0x0000560191053119 in main_loop_wait (nonblocking=0) at /home/user/git/qemu/util/main-loop.c:497 +#4 0x0000560190baf454 in main_loop () at /home/user/git/qemu/vl.c:1866 +#5 0x0000560190baa552 in main (argc=71, argv=0x7ffde10e41c8, envp=0x7ffde10e4408) at /home/user/git/qemu/vl.c:4644 + +The used domain definition is: + +<domain type='kvm'> + <name>test</name> + <memory unit='KiB'>716800</memory> + <vcpu placement='static'>2</vcpu> + <iothreads>8</iothreads> + <os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + <kernel>/var/lib/libvirt/images/vmlinuz-4.14.13-200.fc26.x86_64</kernel> + <initrd>/var/lib/libvirt/images/test-image-qemux86_64+modules-4.14.13-200.fc26.x86_64.cpio.gz</initrd> + <cmdline>console=hvc0 STARTUP=shutdown.sh</cmdline> + <boot dev='hd'/> + </os> + <features> + <acpi/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>preserve</on_crash> + <devices> + <emulator>/usr/local/qemu/master/bin/qemu-system-x86_64</emulator> + <controller type='usb' index='0' model='piix3-uhci'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <console type='pty'> + <target type='virtio' port='0'/> + </console> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='none'/> + </devices> +</domain> + +Do you find the cause of the bug and fix it? + +It was fixed with commit 4cf077b59fc73eec29f8b7 (see patch series https://lists.gnu.org/archive/html/qemu-block/2018-09/msg00504.html). + +Ok, so marking this bug as "fixed" according to Marc's comment. + diff --git a/results/classifier/105/KVM/1792523 b/results/classifier/105/KVM/1792523 new file mode 100644 index 00000000..1435799c --- /dev/null +++ b/results/classifier/105/KVM/1792523 @@ -0,0 +1,90 @@ +KVM: 0.903 +instruction: 0.865 +boot: 0.863 +other: 0.849 +device: 0.831 +graphic: 0.828 +vnc: 0.826 +mistranslation: 0.819 +network: 0.817 +assembly: 0.807 +semantic: 0.781 +socket: 0.772 + +usb passthrough not resetting on host after vm shutdown if started with -daemonize + +Below is the full Qemu command used to launch the VM. Have been using this same setup since Qemu 2.12, plus a couple of cherry picked patch commits fixing ide-hd and e1000e in Windows guests. Both sets of patches have now been merged to 3.0, so decided to update to 3.0. + +The VM launches and runs fine, but after shutting down, the usb devices that are passed through from the host (keyboard, mouse) do not work until unplugged and plugged in again. Have narrowed this down to the -daemonize -pidfile arguments.. if those lines are removed, usb devices work in the host again right away after VM shutdown. + +CPU: Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz +OS: Linux dev 4.18.6-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 5 11:54:09 UTC 2018 x86_64 GNU/Linux + +Thank you for looking into this! + + +#!/usr/bin/env bash + +echo vfio-pci > /sys/bus/pci/devices/0000:04:00.0/driver_override +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers/vfio-pci/bind +echo > /sys/bus/pci/devices/0000:04:00.0/driver_override + +/usr/bin/qemu-system-x86_64 \ +-name winnt \ +-daemonize \ +-pidfile /run/vms/qemu/winnt.pid \ +-boot menu=on \ +-drive if=pflash,format=raw,readonly,file=/opt/vms/qemu/machines/ovmf_code_patched.fd \ +-drive if=pflash,format=raw,file=/opt/vms/qemu/machines/winnt/ovmf_vars_patched.fd \ +-machine pc-q35-3.0,accel=kvm \ +-nodefaults \ +-cpu host,kvm=off,hv_vendor_id=RedHat,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff \ +-accel kvm \ +-smp 4,sockets=1,cores=4,threads=1 \ +-m 16G \ +-nic bridge,br=br0,mac=52:54:00:12:34:77,model=e1000e \ +-device vfio-pci,host=01:00.0,multifunction=on \ +-device vfio-pci,host=01:00.1 \ +-vga none \ +-display none \ +-monitor none \ +-blockdev raw,node-name=ide-hd.0,cache.direct=on,discard=unmap,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_181265803048 \ +-device ide-hd,drive=ide-hd.0,bus=ide.0,rotation_rate=1 \ +-blockdev raw,node-name=ide-hd.1,cache.direct=on,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-TOSHIBA_HDWE160_X746K8ZTF56D-part1 \ +-device ide-hd,drive=ide-hd.1,bus=ide.1 \ +-device vfio-pci,host=04:00.0 \ +-device qemu-xhci \ +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers_probe + +To clarify, are the problematic USB passthrough devices these: + +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +or this: + +-device vfio-pci,host=04:00.0 \ + +Without knowing what the vfio-pci devices are (assuming 1:00.x is GPU+audio), I don't know if passthrough is being used as a colloquial for device assignment or if the issue is really with the usb-host devices. + +The usb-host devices have the problem. + +It does not seem to matter if 1 or all 3 are specified.. I had thought maybe only one of them was causing the issue.. but all of them are affected if '-daemonize' is specified at startup. + +Correct, the vfio-pci device 1:00.x is an Nvidia GPU+audio, and 4:00.0 is an Asmedia USB controller. + +But all of the vfio arguments and binding parts of this script can be removed, and replaced with '-vga std -display gtk' arguments, and the host has the same behavior of not regaining control of the usb-host devices until they are unplugged and plugged back in after the VM shuts down. + +No messages appear in dmesg or any stdout from Qemu related to errors or USB that stand out to me as a problem.. I am happy to try any suggestions to further narrow down the cause. + +Thanks for replying! + +I tested this again on the latest Qemu and Linux kernel and cannot reproduce it anymore, so this can be closed now.. + diff --git a/results/classifier/105/KVM/1798057 b/results/classifier/105/KVM/1798057 new file mode 100644 index 00000000..f778a1e8 --- /dev/null +++ b/results/classifier/105/KVM/1798057 @@ -0,0 +1,55 @@ +KVM: 0.665 +graphic: 0.612 +semantic: 0.609 +other: 0.544 +instruction: 0.523 +device: 0.479 +socket: 0.376 +network: 0.329 +mistranslation: 0.301 +vnc: 0.284 +boot: 0.256 +assembly: 0.092 + +Not able to start instances larger than 1 TB + +Specs: + +CPU: Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz +OS: Ubuntu 18.04 AMD64 +QEMU: 1:2.11+dfsg-1ubuntu7.6 (Ubuntu Bionic Package) +Openstack: Openstack Queens (Ubuntu Bionic Package) +Libvirt-daemon: 4.0.0-1ubuntu8.5 +Seabios: 1.10.2-1ubuntu1 + + +The Problem: +We are not able to start instances, which have a memory size over 1 TB. +After starting the instance, they shortly lock up. Starting guests with a lower amount of RAM works +perfectly. We dealt with the same problem in the past with an older Qemu Version (2.5) by patching some source files according to this patch: + +https://git.centos.org/blob/rpms!!qemu-kvm.git/34b32196890e2c41b0aee042e600ba422f29db17/SOURCES!kvm-fix-guest-physical-bits-to-match-host-to-go-beyond-1.patch + + +I think we now have somewhat the same problem here, however the source base changed and I'am not able to find the corresponding snippet to patch this. + +Also, guests show a wrong physical address size which is probably the cause of the lock ups on high memory guests: +root@debug:~# grep physical /proc/cpuinfo +physical id : 0 +address sizes : 40 bits physical, 48 bits virtual + +Any way to fix this? + +Hi Alex, + You should be able to fix this by passing the right cpu flags, e.g.: + +-cpu IvyBridge,host-phys-bits=yes + +or + +-cpu IvyBridge,physbits=46 + +Dave + +I'm assuming that the right physbits setting fixed the bug? ... so I'm marking this ticket as "Invalid". If the problem still persists, then please open again. + diff --git a/results/classifier/105/KVM/1807052 b/results/classifier/105/KVM/1807052 new file mode 100644 index 00000000..bdfa0280 --- /dev/null +++ b/results/classifier/105/KVM/1807052 @@ -0,0 +1,375 @@ +KVM: 0.687 +vnc: 0.588 +mistranslation: 0.556 +other: 0.497 +boot: 0.446 +instruction: 0.444 +graphic: 0.444 +network: 0.440 +device: 0.427 +socket: 0.412 +assembly: 0.406 +semantic: 0.397 + +Qemu hangs during migration + +Source server: linux 4.19.5 qemu-3.0.0 from source, libvirt 4.9 +Dest server: linux 4.18.19 qemu-3.0.0 from source, libvirt 4.9 + +When this VM is running on source server: + +/usr/bin/qemu-system-x86_64 -name guest=testvm,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-testvm/master-key.aes -machine pc-q35-3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 3b00b788-ee91-4e45-80a6-c7319da71225 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=23,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-pci-bridge,id=pci.3,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 -device piix3-usb-uhci,id=usb,bus=pci.3,addr=0x1 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pci.4,addr=0x0 -drive file=/dev/zvol/datastore/vm/testvm-vda,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on -drive if=none,id=drive-sata0-0-4,media=cdrom,readonly=on -device ide-cd,bus=ide.4,drive=drive-sata0-0-4,id=sata0-0-4,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a2:b7:a1,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 -s -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +I try to migrate it and the disks to the other side: + +virsh migrate --live --undefinesource --persistent --verbose --copy-storage-all testvm qemu+ssh://wasvirt1/system + +We get to 99% then hang with both sides in the pause state. + +Source server is stuck here: +(gdb) bt full +#0 0x00007f327994f3c1 in ppoll () at /lib64/libc.so.6 +#1 0x000000000086167b in qemu_poll_ns (fds=<optimized out>, nfds=nfds@entry=1, timeout=<optimized out>) at util/qemu-timer.c:322 +#2 0x0000000000863302 in aio_poll (ctx=0x21044e0, blocking=blocking@entry=true) at util/aio-posix.c:629 + node = <optimized out> + i = <optimized out> + ret = 0 + progress = <optimized out> + timeout = <optimized out> + start = <optimized out> + __PRETTY_FUNCTION__ = "aio_poll" +#3 0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:62 + waited_ = <optimized out> + wait_ = 0x2ba563c + ctx_ = 0x2109bb0 + bs_ = 0x2ba2400 + client = 0x31287e0 + client = <optimized out> + request = {handle = 0, from = 0, len = 0, flags = 0, type = 2} +#4 0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:965 + client = <optimized out> + request = {handle = 0, from = 0, len = 0, flags = 0, type = 2} +#5 0x00000000007de5ca in nbd_close (bs=<optimized out>) at block/nbd.c:491 + s = 0x31287e0 +#6 0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3352 + ban = <optimized out> + ban_next = <optimized out> + child = <optimized out> + next = <optimized out> +#7 0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3560 +#8 0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:4616 +#9 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3359 + ban = <optimized out> + ban_next = <optimized out> + child = <optimized out> + next = <optimized out> +#10 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3560 +#11 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:4616 +#12 0x0000000000785784 in block_job_remove_all_bdrv (job=job@entry=0x2f32570) at blockjob.c:200 + c = 0x23bac30 + l = 0x20dd330 = {0x23bac30, 0x2b89410} +#13 0x00000000007ceb5f in mirror_exit (job=0x2f32570, opaque=0x7f326407a350) at block/mirror.c:700 + s = 0x2f32570 + bjob = 0x2f32570 + data = 0x7f326407a350 + bs_opaque = 0x30d5600 + replace_aio_context = <optimized out> + src = 0x2131080 + target_bs = 0x2af96f0 + mirror_top_bs = 0x210eb70 + local_err = 0x0 +#14 0x0000000000786452 in job_defer_to_main_loop_bh (opaque=0x7f32640786a0) at job.c:973 + data = 0x7f32640786a0 + job = <optimized out> + aio_context = 0x2109bb0 +#15 0x000000000085fd3f in aio_bh_poll (ctx=ctx@entry=0x21044e0) at util/async.c:118 +---Type <return> to continue, or q <return> to quit--- + bh = <optimized out> + bhp = <optimized out> + next = 0x2ea86e0 + ret = 1 + deleted = false +#16 0x00000000008631b0 in aio_dispatch (ctx=0x21044e0) at util/aio-posix.c:436 +#17 0x000000000085fc1e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:261 + ctx = <optimized out> +#18 0x00007f327f17d797 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 +#19 0x00000000008622ed in main_loop_wait () at util/main-loop.c:215 + context = 0x2104900 + pfds = <optimized out> + context = 0x2104900 + ret = 1 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#20 0x00000000008622ed in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:238 + context = 0x2104900 + ret = 1 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#21 0x00000000008622ed in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#22 0x0000000000595dee in main_loop () at vl.c:1866 +#23 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 71 + optarg = 0x7ffdfc94df69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7ffdfc94d864 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x0 + userconfig = <optimized out> +---Type <return> to continue, or q <return> to quit--- + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdfc94c170} + __func__ = "main" + +Strace shows: +ppoll([{fd=9, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8 + +Which points to this: + +ls -al /proc/2286/fd/9 +lrwx------ 1 root users 64 Dec 5 13:04 /proc/2286/fd/9 -> anon_inode:[eventfd] + +The dest side is stuck here: + +(gdb) bt full +#0 0x00007f21f070d3c1 in ppoll () at /lib64/libc.so.6 +#1 0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999926258) at util/qemu-timer.c:334 + ts = {tv_sec = 2, tv_nsec = 999926258} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233 + context = 0x2142900 + ret = <optimized out> + ret = -1295041038 + timeout = 4294967295 + timeout_ns = <optimized out> +#3 0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = -1295041038 + timeout = 4294967295 + timeout_ns = <optimized out> +#4 0x0000000000595dee in main_loop () at vl.c:1866 +#5 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 73 + optarg = 0x7ffdd6ee8f69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7ffdd6ee8854 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x7ffdd6ee8f0a "defer" + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdd6ee6630} +---Type <return> to continue, or q <return> to quit--- + __func__ = "main" + +Strace show this over and over +ppoll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=27, events=POLLIN}], 9, {0, 594527977}, NULL, 8) = 0 (Timeout) + +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/10 -> anon_inode:[eventfd] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/21 -> socket:[42631161] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/22 -> socket:[42631165] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/23 -> socket:[42631167] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/24 -> socket:[42631168] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/27 -> socket:[42690422] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/6 -> anon_inode:[eventfd] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/7 -> anon_inode:[signalfd] +lrwx------ 1 root users 64 Dec 5 13:15 /proc/20170/fd/9 -> anon_inode:[eventfd] + +If I remote iothreads and writeback caching, it seems more reliable, but I can still get it to hang. + +This time the source server shows the VM as running, backtrace looks like: + +(gdb) bt full +#0 0x00007f27eab0028c in __lll_lock_wait () at /lib64/libpthread.so.0 +#1 0x00007f27eaaf9d35 in pthread_mutex_lock () at /lib64/libpthread.so.0 +#2 0x0000000000865419 in qemu_mutex_lock_impl (mutex=mutex@entry=0x115b8e0 <qemu_global_mutex>, file=file@entry=0x8fdf14 "/tmp/qemu-3.0.0/cpus.c", line=line@entry=1768) + at util/qemu-thread-posix.c:66 + err = <optimized out> + __PRETTY_FUNCTION__ = "qemu_mutex_lock_impl" + __func__ = "qemu_mutex_lock_impl" +#3 0x0000000000477578 in qemu_mutex_lock_iothread () at /tmp/qemu-3.0.0/cpus.c:1768 +#4 0x00000000008622b0 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:236 + context = 0x1e72810 + ret = 1 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#5 0x00000000008622b0 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = 1 + timeout = 4294967295 + timeout_ns = <optimized out> +#6 0x0000000000595dee in main_loop () at vl.c:1866 +#7 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 71 + optarg = 0x7fff5edcff69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7fff5edcf88a "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x7fff5edcff0a "defer" + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 +---Type <return> to continue, or q <return> to quit--- + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7fff5edcd670} + __func__ = "main" + + +Dest server is paused, and looks like this: + +#0 0x00007f11c48bc3c1 in ppoll () at /lib64/libc.so.6 +#1 0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999892383) at util/qemu-timer.c:334 + ts = {tv_sec = 2, tv_nsec = 999892383} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233 + context = 0x2342810 + ret = <optimized out> + ret = -1295074913 + timeout = 4294967295 + timeout_ns = <optimized out> +#3 0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497 + ret = -1295074913 + timeout = 4294967295 + timeout_ns = <optimized out> +#4 0x0000000000595dee in main_loop () at vl.c:1866 +#5 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x918f44 "cad" + boot_once = 0x0 + ds = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 71 + optarg = 0x7ffe6b899f69 "timestamp=on" + loadvm = 0x0 + machine_class = 0x0 + cpu_model = 0x7ffe6b89988a "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"... + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = <optimized out> + incoming = 0x7ffe6b899f0a "defer" + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = 4294967296 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dir = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe6b8988e0} +---Type <return> to continue, or q <return> to quit--- + __func__ = "main" + +Honestly looks pretty much like the same 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/105/KVM/1808 b/results/classifier/105/KVM/1808 new file mode 100644 index 00000000..4f336679 --- /dev/null +++ b/results/classifier/105/KVM/1808 @@ -0,0 +1,84 @@ +KVM: 0.381 +graphic: 0.378 +instruction: 0.370 +vnc: 0.361 +other: 0.357 +mistranslation: 0.343 +device: 0.340 +boot: 0.312 +assembly: 0.290 +network: 0.282 +semantic: 0.274 +socket: 0.260 + +qemu-system-i386: Crash in tcg_handle_interrupt on fpu_raise_exception call +Description of problem: +While I was messing with an old Linux system, QEMU crashed as I tried to run `make test` on a package: +``` +ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:83:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +``` +Running QEMU straight from the master branch (c167c80) didn't help either. The backtrace is as follows: +``` +(gdb) bt +#0 0x00007ffff55ac26c in () at /usr/lib/libc.so.6 +#1 0x00007ffff555ca08 in raise () at /usr/lib/libc.so.6 +#2 0x00007ffff5545538 in abort () at /usr/lib/libc.so.6 +#3 0x00007ffff6bae05e in g_assertion_message + (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", message=message@entry=0x7fff9c15ee10 "assertion failed: (qemu_mutex_iothread_locked())") at ../glib/glib/gtestutils.c:3450 +#4 0x00007ffff6c0ef40 in g_assertion_message_expr + (domain=domain@entry=0x0, file=file@entry=0x555555f90a98 "../accel/tcg/tcg-accel-ops.c", line=line@entry=83, func=func@entry=0x55555607a130 <__func__.3> "tcg_handle_interrupt", expr=expr@entry=0x555555f79cf8 "qemu_mutex_iothread_locked()") at ../glib/glib/gtestutils.c:3476 +#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83 +#6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81 +#7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555 +#8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611 +#9 0x00007fffa42bde14 in code_gen_buffer () +#10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457 +#11 0x0000555555c7298e in cpu_loop_exec_tb (tb_exit=0x7fffe9bfd658, last_tb=<synthetic pointer>, pc=3221283547, tb=<optimized out>, cpu=<optimized out>) at ../accel/tcg/cpu-exec.c:919 +#12 cpu_exec_loop (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1040 +#13 0x0000555555c731dd in cpu_exec_setjmp (cpu=cpu@entry=0x555557434cb0, sc=sc@entry=0x7fffe9bfd6f0) at ../accel/tcg/cpu-exec.c:1057 +#14 0x0000555555c73810 in cpu_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/cpu-exec.c:1083 +#15 0x0000555555c974ff in tcg_cpus_exec (cpu=cpu@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops.c:75 +#16 0x0000555555c97657 in mttcg_cpu_thread_fn (arg=arg@entry=0x555557434cb0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#17 0x0000555555e283e8 in qemu_thread_start (args=0x5555574935f0) at ../util/qemu-thread-posix.c:541 +#18 0x00007ffff55aa44b in () at /usr/lib/libc.so.6 +#19 0x00007ffff562de40 in () at /usr/lib/libc.so.6 +``` + +After further testing, it seems related to inftest.awk. However, the crash doesn't occur right after I run the file, but only when I do specific operations afterwards. + +With `-accel kvm` +``` +> gawk -f test/inftest.awk +(output trimmed) +1e+305 1e+302 +1e+308 1e+305 +gawk: test/inftest.awk:3: fatal: floating point exception +> echo Test # No crash +Test +> cat test/inftest.awk # No crash +``` + +With `-accel tcg` +``` +> gawk -f test/inftest.awk +(output trimmed) +1e+308 1e+305 +Infinity 1e+308 +Infinity Infinity +loop terminated +> echo Test # No crash +Test +> cat test/inftest.awk # QEMU crash +``` +Steps to reproduce: +1. Start the VM +2. Press any key except for enter to go through the SVGA prompt +3. Enter `root` to login. No password is required +4. Run `cd /usr/src2/gawk-2.14` +5. Run `gawk -f test/inftest.awk` +6. Run certain commands that interact with the kernel (ex. `ls`, `cat test/inftest.awk`, `whoami`) +7. Observe the crash +Additional information: +[00000-bootFloppy.raw](/uploads/379f6b601132980af4ea721fe77dbae4/00000-bootFloppy.raw) +[artifact.qcow2](/uploads/d721a35bc55e764e17087e8bc1a7531e/artifact.qcow2) diff --git a/results/classifier/105/KVM/1808928 b/results/classifier/105/KVM/1808928 new file mode 100644 index 00000000..28358648 --- /dev/null +++ b/results/classifier/105/KVM/1808928 @@ -0,0 +1,126 @@ +KVM: 0.774 +mistranslation: 0.745 +vnc: 0.738 +other: 0.719 +graphic: 0.714 +device: 0.692 +boot: 0.650 +instruction: 0.631 +assembly: 0.629 +semantic: 0.619 +network: 0.562 +socket: 0.503 + +Bitmap Extra data is not supported + +i am using dirty bitmaps and drive-backup. It works as aspected. + +Lately, i encounter a disastrous error. There is not any information about that situation. I cannot reach/open/attach/info or anything with a qcow2 file. + +virsh version +Compiled against library: libvirt 4.10.0 +Using library: libvirt 4.10.0 +Using API: QEMU 4.10.0 +Running hypervisor: QEMU 2.12.0 + +"qemu-img: Could not open '/var/lib/libvirt/images/test.qcow2': Bitmap extra data is not supported" + +what is that mean? what should i do? +i cannot remove bitmap. i cannot open image or query. + +Hi, bitmap extensions have a field that allows us to attach extra/arbitrary data to them. It is not currently used by QEMU. If this field is set, it means something corrupted your qcow2. + +Please make a backup of your qcow2 file first (because attempting to repair a broken qcow2 can sometimes make it worse), and then please try running qemu-img check to try and diagnose the image. + +What happened to cause the "disastrous error", do you recall? + +as far as i know nothing happened. it had worked normally while instance was running. For a reason, instance is shutdown, then it never open again. i have some backups, i tried to return previous backups. But they also gave same error. Thanks to replication i could get it back. i copied image from replication site... + +as i said "qemu-img" command completely unusable on that image. +There should be another mechanism. It blocks everything. +I try to edit header to remove extra data. But i could not find header information on website. + +thanks + +OK, I think it is a bug that you cannot at least repair the image, though the cause of corruption is still unknown to me. Do you have libvirt/QEMU logs from when then VM was shut down, before it wouldn't boot properly again? + +Sorry, because of log time, VM logs were removed. Journalctl for libvirtd is remain.. It was like that. +018-12-17 17:01:50.990+0000: 43198: error : qemuMonitorIORead:606 : Unable to read from monitor: Connection reset by peer +Dec 17 20:01:50 vm-kvm09 libvirtd[43198]: 2018-12-17 17:01:50.991+0000: 43198: error : qemuProcessReportLogError:1935 : internal error: qemu unexpectedly closed the monitor: .guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio +Dec 17 20:01:51 vm-kvm09 libvirtd[43198]: 2018-12-17T17:01:50.984315Z qemu-kvm: -drive file=/var/lib/libvirt/images/exo1-jb-h01-2.qcow2,format=qcow2,if=none,id=drive-virtio-disk1,cache=none: Bitmap extra data is not supported +Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.652+0000: 43203: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info +Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.668+0000: 68990: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info +Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.683+0000: 17099: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info +Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.700+0000: 68889: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info +Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.717+0000: 43200: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info +Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.732+0000: 43202: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info +Dec 17 20:09:59 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:59.144+0000: 43198: error : qemuMonitorIORead:606 : Unable to read from monitor: Connection reset by peer +Dec 17 20:09:59 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:59.145+0000: 43198: error : qemuProcessReportLogError:1935 : internal error: qemu unexpectedly closed the monitor: 2018-12-17T17:09:59.132340Z qemu-kvm: -drive file=/var/lib/libvirt/images/exo1-jb-h01-2.qcow2,f... + +I keep the broken image file. I run some qemu-img commands: + +> qemu-img check /var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712 +qemu-img: Could not open '/var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712': Bitmap extra data is not supported + +> qemu-img info /var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712 +qemu-img: Could not open '/var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712': Bitmap extra data is not supported + + + + + + +For now, QEMU cannot accept images with extra bitmap data, because QEMU isn't aware of the semantics of those fields, so we cannot even allow the image to load, just in case. + +However, we SHOULD allow qemu-img check --repair to detect such bitmaps as corruption so that images can be scrubbed and recovered. I will add that to my TODO list. + +Meanwhile, I believe the root cause of your problem here is a data corruption event, but it's hard to tell exactly what it might be because of the extra_data flag ... I can try to have some patches ready for you in January that try to "ignore" the data and analyze the rest of the image as best as possible, which might help us see what else went wrong. + +John, did you find some spare time to work on those patches that you've mentioned? I.e. has this been addressed already? + +my patches went in, ultimately, and my focus was since shifted elsewhere. I just tried this by *manually* adding some extra data to a bitmap by hand. + + +qemu-img create -f qcow2 foo.qcow2 64m +qemu-img bitmap --add foo.qcow2 mybitmap + +This creates a bitmap extension header like this (starting at 0x1f8) + +000001f0 00 00 00 00 00 00 00 00 23 85 28 75 00 00 00 18 |........#.(u....| +00000200 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 20 |............... | +00000210 00 00 00 00 00 05 00 00 |........ | + +And a bitmap table that looks like this: + +00050000 00 00 00 00 00 04 00 00 00 00 00 01 00 00 00 02 |................| +00050010 01 10 00 08 00 00 00 00 6d 79 62 69 74 6d 61 70 |........mybitmap| + +I modified the bitmap table to add eight bytes of bad data: + +00050000 00 00 00 00 00 04 00 00 00 00 00 01 00 00 00 02 |................| +00050010 01 10 00 08 00 00 00 08 62 61 64 64 61 74 61 21 |........baddata!| +00050020 6d 79 62 69 74 6d 61 70 |mybitmap| + +And modified the header accordingly to add eight bytes to the table (0x20f := 0x28): + +000001f0 00 00 00 00 00 00 00 00 23 85 28 75 00 00 00 18 |........#.(u....| +00000200 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 28 |...............(| +00000210 00 00 00 00 00 05 00 00 |........ | + +And in these cases, QEMU refuses to load or work with the image even slightly, rendering you unable to remove it: + +> ./qemu-img bitmap --remove foo.qcow2 mybitmap +qemu-img: Could not open 'foo.qcow2': Bitmap extra data is not supported + +So, it's still an open issue. + +Sorry, that formatted *terribly*... please see the attachment for a raw text version with arbitrarily long columns that looks nicer. :( + + +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/58 + + diff --git a/results/classifier/105/KVM/1814418 b/results/classifier/105/KVM/1814418 new file mode 100644 index 00000000..16f6de26 --- /dev/null +++ b/results/classifier/105/KVM/1814418 @@ -0,0 +1,543 @@ +KVM: 0.671 +other: 0.666 +vnc: 0.652 +boot: 0.639 +mistranslation: 0.635 +network: 0.635 +instruction: 0.627 +assembly: 0.617 +socket: 0.617 +device: 0.616 +semantic: 0.610 +graphic: 0.609 + +persistent bitmap will be inconsistent when qemu crash, + +Follow these steps to reappear the bug: + +1. start qemu +2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}' +3. kill -9 qemu (simulate Host crash, eg. lose power) +4. restart qemu + +Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can understand at this point, because the bitmap0 has not been synchronized yet. + +But, when I try to add persistent bitmap0 again: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}', It failed: + +{"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the same name is already stored"}} + +In other word, when qemu crash, the qcow2 image remain the incomplete persistent bitmap. + +--- + +qemu version: 2.12.0 and 3.1.0, other version I does not test yet. +qemu command: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +On 2/2/19 11:52 PM, Cheng Chen wrote: +> Public bug reported: +> +> Follow these steps to reappear the bug: +> +> 1. start qemu +> 2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}' +> 3. kill -9 qemu (simulate Host crash, eg. lose power) +> 4. restart qemu +> +> Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can +> understand at this point, because the bitmap0 has not been synchronized +> yet. + +This matches my observations here: +https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07700.html + +I'm of the opinion that updating the qcow2 headers any time a persistent +bitmap is created or destroyed is worthwhile, even if the headers must +still mark the bitmap as in-use. True, the crash will leave the bitmap +as inconsistent, which is no different than if the bitmap is never +written to the qcow2 header (when booting a new qemu, an inconsistent +bitmap on disk has the same status as a missing bitmap - both imply that +an incremental backup is not possible, and so a full backup is needed +instead). But the creation of bitmaps is not a common occasion, and +having the metadata track that a persistent bitmap has been requested +seems like it would be useful information during a debugging session. + + +> +> But, when I try to add persistent bitmap0 again: '{ "execute": "block- +> dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": +> "bitmap0", "persistent":true }}', It failed: +> +> {"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make +> bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the +> same name is already stored"}} +> +> In other word, when qemu crash, the qcow2 image remain the incomplete +> persistent bitmap. + +Does Andrey's proposed patch adding persistent bitmap details to +'qemu-img info' show anything after you first kill qemu? + +/me goes and tests... + +Oh weird - with Andrey's patch, we get semi-duplicated information +during query-block (at least, after an initial clean shutdown prior to +attempting an abrupt shutdown): + +{"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, +"removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", +"image": {"virtual-size": 104857600, "filename": "file5", +"cluster-size": 65536, "format": "qcow2", "actual-size": 208896, +"format-specific": {"type": "qcow2", "data": {"compat": "1.1", +"lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"], +"name": "b2", "granularity": 65536}], "refcount-bits": 16, "corrupt": +false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": +"#block172", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, +"bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, +"bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": +true}, "file": "file5", "encryption_key_missing": false}, "qdev": +"/machine/unattached/device[18]", "dirty-bitmaps": [{"name": "b2", +"status": "active", "granularity": 65536, "count": 0}, {"name": "b", +"status": "active", "granularity": 65536, "count": 0}], "type": "unknown"}]} + +Note that the "format-specific" listing has a "bitmaps" entry resulting +from Andrey's patch (which shows "auto" as one of the "flags" for any +persistent bitmap) showing the state of the persistent bitmaps on disk; +as well as the "dirty-bitmaps" entry that shows the state of the bitmaps +in memory. Annoyingly, the "dirty-bitmaps" section does NOT state which +bitmaps are persistent, and if a persistent bitmap has not yet been +flushed to disk, then there is NO way to quickly determine which bitmaps +are persistent and which are transient. + +At any rate, with qemu.git master + Andrey's patches for qemu-img info, +I was able to reproduce a related oddity: attempting to +block-dirty-bitmap-add a transient bitmap that has the same name as an +existing in-use persistent bitmap succeeds; when it should have failed: + +$ qemu-img create -f qcow2 file5 100m +$ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio +file5 +{'execute':'qmp_capabilities'} +{'execute':'query-block'} # learn the node name... +{'execute':'block-dirty-bitmap-add','arguments':{'node':'#block111','name':'b1','persistent':true}} +{'execute':'quit'} +$ ./qemu-img info -U file5 +image: file5 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 204K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + bitmaps: + [0]: + flags: + [0]: auto + name: b1 + granularity: 65536 + refcount bits: 16 + corrupt: false +$ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio +file5 +{'execute':'qmp_capabilities'} +{'execute':'query-block'} +{"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, +"removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", +"image": {"virtual-size": 104857600, "filename": "file5", +"cluster-size": 65536, "format": "qcow2", "actual-size": 208896, +"format-specific": {"type": "qcow2", "data": {"compat": "1.1", +"lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"], +"name": "b1", "granularity": 65536}], "refcount-bits": 16, "corrupt": +false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": +"#block157", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, +"bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, +"bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": +true}, "file": "file5", "encryption_key_missing": false}, "qdev": +"/machine/unattached/device[18]", "dirty-bitmaps": [{"name": "b1", +"status": "active", "granularity": 65536, "count": 0}], "type": "unknown"}]} +$ kill -9 $qemupid +$ ./qemu-img info -U file5 +image: file5 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 204K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + bitmaps: + [0]: + flags: + [0]: in-use + [1]: auto + name: b1 + granularity: 65536 + refcount bits: 16 + corrupt: false +$ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio +file5 +{'execute':'qmp_capabilities'} +{'execute':'query-block'} +{"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, +"removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", +"image": {"virtual-size": 104857600, "filename": "file5", +"cluster-size": 65536, "format": "qcow2", "actual-size": 208896, +"format-specific": {"type": "qcow2", "data": {"compat": "1.1", +"lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"], +"name": "b1", "granularity": 65536}], "refcount-bits": 16, "corrupt": +false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": +"#block141", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, +"bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, +"bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": +true}, "file": "file5", "encryption_key_missing": false}, "qdev": +"/machine/unattached/device[18]", "type": "unknown"}]} + +Note - after the unclean death, the "dirty-bitmaps" entry in query-block +is NOT present, and as a result: + +{'execute':'block-dirty-bitmap-add','arguments':{'node':'#block141','name':'b1'}} +{"return": {}} + +Oops - we were able to add a temporary bitmap that overrides the still +in-use persistent bitmap (which we properly ignored on loading, because +it was marked in-use). + + +> +> --- +> +> qemu version: 2.12.0 and 3.1.0, other version I does not test yet. + +qemu 4.0 promotes various dirty bitmap interfaces from experimental to +supported; flaws in 3.1 are somewhat expected, but we want to make sure +4.0 fixes such problems, so we indeed have a bug here. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + +On 2/4/19 8:55 AM, Eric Blake wrote: + +> +> Note that the "format-specific" listing has a "bitmaps" entry resulting +> from Andrey's patch (which shows "auto" as one of the "flags" for any +> persistent bitmap) showing the state of the persistent bitmaps on disk; +> as well as the "dirty-bitmaps" entry that shows the state of the bitmaps +> in memory. Annoyingly, the "dirty-bitmaps" section does NOT state which +> bitmaps are persistent, and if a persistent bitmap has not yet been +> flushed to disk, then there is NO way to quickly determine which bitmaps +> are persistent and which are transient. + +I've posted a patch for this side-issue: + +https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg00759.html + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + +Thanks, all: + +I only want to know: + +1. Is this a bug? +2. Which qemu version will fix the bug? + + + +On 2/4/19 11:22 AM, Vladimir Sementsov-Ogievskiy wrote: +> 04.02.2019 17:55, Eric Blake wrote: +>> On 2/2/19 11:52 PM, Cheng Chen wrote: +>>> Public bug reported: +>>> +>>> Follow these steps to reappear the bug: +>>> +>>> 1. start qemu +>>> 2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}' +>>> 3. kill -9 qemu (simulate Host crash, eg. lose power) +>>> 4. restart qemu +>>> +>>> Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can +>>> understand at this point, because the bitmap0 has not been synchronized +>>> yet. +>> +>> This matches my observations here: +>> https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07700.html +>> +>> I'm of the opinion that updating the qcow2 headers any time a persistent +>> bitmap is created or destroyed is worthwhile, even if the headers must +>> still mark the bitmap as in-use. True, the crash will leave the bitmap +>> as inconsistent, which is no different than if the bitmap is never +>> written to the qcow2 header (when booting a new qemu, an inconsistent +>> bitmap on disk has the same status as a missing bitmap - both imply that +>> an incremental backup is not possible, and so a full backup is needed +>> instead). But the creation of bitmaps is not a common occasion, and +>> having the metadata track that a persistent bitmap has been requested +>> seems like it would be useful information during a debugging session. +> +> Even if we store them, following query-block will not show them, as +> in-use bitmaps are not loaded on open (or, we should load them too). +> +>> +>> +>>> +>>> But, when I try to add persistent bitmap0 again: '{ "execute": "block- +>>> dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": +>>> "bitmap0", "persistent":true }}', It failed: +>>> +>>> {"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make +>>> bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the +>>> same name is already stored"}} +>>> +>>> In other word, when qemu crash, the qcow2 image remain the incomplete +>>> persistent bitmap. +> +> Yes (if it was stored at least once, may be on previous qemu run). +> +>> +>> Does Andrey's proposed patch adding persistent bitmap details to +>> 'qemu-img info' show anything after you first kill qemu? +>> +>> /me goes and tests... +>> +>> Oh weird - with Andrey's patch, we get semi-duplicated information +>> during query-block (at least, after an initial clean shutdown prior to +>> attempting an abrupt shutdown): +>> +>> {"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, +>> "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", +>> "image": {"virtual-size": 104857600, "filename": "file5", +>> "cluster-size": 65536, "format": "qcow2", "actual-size": 208896, +>> "format-specific": {"type": "qcow2", "data": {"compat": "1.1", +>> "lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"], +>> "name": "b2", "granularity": 65536}], "refcount-bits": 16, "corrupt": +>> false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": +>> "#block172", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, +>> "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, +>> "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": +>> true}, "file": "file5", "encryption_key_missing": false}, "qdev": +>> "/machine/unattached/device[18]", "dirty-bitmaps": [{"name": "b2", +>> "status": "active", "granularity": 65536, "count": 0}, {"name": "b", +>> "status": "active", "granularity": 65536, "count": 0}], "type": "unknown"}]} +>> +>> Note that the "format-specific" listing has a "bitmaps" entry resulting +>> from Andrey's patch (which shows "auto" as one of the "flags" for any +>> persistent bitmap) showing the state of the persistent bitmaps on disk; +>> as well as the "dirty-bitmaps" entry that shows the state of the bitmaps +>> in memory. Annoyingly, the "dirty-bitmaps" section does NOT state which +>> bitmaps are persistent, and if a persistent bitmap has not yet been +>> flushed to disk, then there is NO way to quickly determine which bitmaps +>> are persistent and which are transient. +>> +>> At any rate, with qemu.git master + Andrey's patches for qemu-img info, +>> I was able to reproduce a related oddity: attempting to +>> block-dirty-bitmap-add a transient bitmap that has the same name as an +>> existing in-use persistent bitmap succeeds; when it should have failed: +>> +>> $ qemu-img create -f qcow2 file5 100m +>> $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio +>> file5 +>> {'execute':'qmp_capabilities'} +>> {'execute':'query-block'} # learn the node name... +>> {'execute':'block-dirty-bitmap-add','arguments':{'node':'#block111','name':'b1','persistent':true}} +>> {'execute':'quit'} +>> $ ./qemu-img info -U file5 +>> image: file5 +>> file format: qcow2 +>> virtual size: 100M (104857600 bytes) +>> disk size: 204K +>> cluster_size: 65536 +>> Format specific information: +>> compat: 1.1 +>> lazy refcounts: false +>> bitmaps: +>> [0]: +>> flags: +>> [0]: auto +>> name: b1 +>> granularity: 65536 +>> refcount bits: 16 +>> corrupt: false +>> $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio +>> file5 +>> {'execute':'qmp_capabilities'} +>> {'execute':'query-block'} +>> {"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, +>> "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", +>> "image": {"virtual-size": 104857600, "filename": "file5", +>> "cluster-size": 65536, "format": "qcow2", "actual-size": 208896, +>> "format-specific": {"type": "qcow2", "data": {"compat": "1.1", +>> "lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"], +>> "name": "b1", "granularity": 65536}], "refcount-bits": 16, "corrupt": +>> false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": +>> "#block157", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, +>> "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, +>> "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": +>> true}, "file": "file5", "encryption_key_missing": false}, "qdev": +>> "/machine/unattached/device[18]", "dirty-bitmaps": [{"name": "b1", +>> "status": "active", "granularity": 65536, "count": 0}], "type": "unknown"}]} +>> $ kill -9 $qemupid +>> $ ./qemu-img info -U file5 +>> image: file5 +>> file format: qcow2 +>> virtual size: 100M (104857600 bytes) +>> disk size: 204K +>> cluster_size: 65536 +>> Format specific information: +>> compat: 1.1 +>> lazy refcounts: false +>> bitmaps: +>> [0]: +>> flags: +>> [0]: in-use +>> [1]: auto +>> name: b1 +>> granularity: 65536 +>> refcount bits: 16 +>> corrupt: false +>> $ ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic -qmp stdio +>> file5 +>> {'execute':'qmp_capabilities'} +>> {'execute':'query-block'} +>> {"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, +>> "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", +>> "image": {"virtual-size": 104857600, "filename": "file5", +>> "cluster-size": 65536, "format": "qcow2", "actual-size": 208896, +>> "format-specific": {"type": "qcow2", "data": {"compat": "1.1", +>> "lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"], +>> "name": "b1", "granularity": 65536}], "refcount-bits": 16, "corrupt": +>> false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": +>> "#block141", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, +>> "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, +>> "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": +>> true}, "file": "file5", "encryption_key_missing": false}, "qdev": +>> "/machine/unattached/device[18]", "type": "unknown"}]} +>> +>> Note - after the unclean death, the "dirty-bitmaps" entry in query-block +>> is NOT present, and as a result: +>> +>> {'execute':'block-dirty-bitmap-add','arguments':{'node':'#block141','name':'b1'}} +>> {"return": {}} +>> +>> Oops - we were able to add a temporary bitmap that overrides the still +>> in-use persistent bitmap (which we properly ignored on loading, because +>> it was marked in-use). +> +> Yes, but you will not be able to create persistent bitmap with the same name as +> in-use bitmap in the image, so, there is no actual collision.. But is not good +> too. +> +> In-use bitmaps in the image may appear only after some kind of qemu crash. Isn't +> it a good reason to call qemu-img check? So, haw about just forbid to start qemu +> if there are any in-use bitmaps? +> + +I have wondered this recently. + +I am against just silently loading and deleting the bitmaps because I +don't want any chance for data corruption if the bitmap gets lost +accidentally. I like the loud failure. + +I kind of like the idea of just failing to load the image at all, +because it does necessitate user action, but it feels a little user hostile. + +Maybe we can do some kind of soft-load for corrupted bitmaps where they +will remain "locked" and cannot be re-written to disk until the user +issues a clear command to reset them -- so the user knows full well the +backup chain is broken. Maybe this is a good solution to the problem? + +What do you think? + +--js + + + + +On 2/12/19 5:56 AM, Vladimir Sementsov-Ogievskiy wrote: +> 12.02.2019 4:10, John Snow wrote: +>> On 2/4/19 11:22 AM, Vladimir Sementsov-Ogievskiy wrote: + +>>> In-use bitmaps in the image may appear only after some kind of qemu crash. Isn't +>>> it a good reason to call qemu-img check? So, haw about just forbid to start qemu +>>> if there are any in-use bitmaps? +>>> +>> +>> I have wondered this recently. +>> +>> I am against just silently loading and deleting the bitmaps because I +>> don't want any chance for data corruption if the bitmap gets lost +>> accidentally. I like the loud failure. +>> +>> I kind of like the idea of just failing to load the image at all, +>> because it does necessitate user action, but it feels a little user hostile. +> +> Yes, it may be to noisy to have to call qemu-img check after any unexpected process +> kill, and it's not like real machine behave. +> +>> +>> Maybe we can do some kind of soft-load for corrupted bitmaps where they +>> will remain "locked" and cannot be re-written to disk until the user +>> issues a clear command to reset them -- so the user knows full well the +>> backup chain is broken. Maybe this is a good solution to the problem? +>> +>> What do you think? +> +> It should not be just "locked", it should be visibly "corrupted", for user to understand +> the reason of why bitmap is unusable. So, it should be a new state of flag. +> + +Right, sure. It will behave similarly to a locked, disabled bitmap. You +can't do anything to it, it doesn't record writes, etc. A new flag is +helpful for the purpose. + +> So, instead of just ignoring in-use bitmaps on start, we load them, benefit of +> having them in list, but the only thing which can be done with them is +> block-dirty-bitmap-remove (and it's additional reason, why it can't be "locked" state). +> + +I'd say remove or clear, both would make sense. I suppose we only *need* +one and remove covers all cases, so I'll go with this suggestion and +offer clear as an additional patch that we could take or leave. + +> I'm not sure that we should load data for such bitmaps, so they may be loaded as +> BdrvDirtyBitmaps with .corrupted = true and .bitmap = NULL. +> + +Probably doesn't hurt to just load a blank bitmap instead of trying to +special case it with the NULL, but understood: we don't have to load the +data because it's junk. + +> +> Hmm, go and check that it will not break bitmaps migration related logic, which is described +> in BIG comment in block/qcow2.c. Looks like all is ok, and in only valid case when we could +> see in-use bitmaps is +> +> * One remaining possible case when we don't want load bitmaps: +> * +> * 4. Open disk in inactive mode in target vm (bitmaps are migrating or +> * will be loaded on invalidation, no needs try loading them before) +> +> +> and we don't try loading bitmaps in this case: +> +> if (!(bdrv_get_flags(bs) & BDRV_O_INACTIVE)) { +> < load bitmaps > +> +> So the only thing to do additionally here is enhance the comment, to +> s/no needs/must not do it, as they will be loaded as corrupted/. +> +> + +Sounds good to me, I'll get cooking. + + +This has been checked in upstream and is pending release for 4.0; + +QEMU will now load inconsistent bitmaps and expose them with a status of "Inconsistent" and an extra boolean inconsistent = true. + +You can remove them with block-dirty-bitmap-remove. + diff --git a/results/classifier/105/KVM/1814420 b/results/classifier/105/KVM/1814420 new file mode 100644 index 00000000..fd19a1f8 --- /dev/null +++ b/results/classifier/105/KVM/1814420 @@ -0,0 +1,45 @@ +KVM: 0.845 +mistranslation: 0.770 +vnc: 0.720 +other: 0.681 +boot: 0.648 +instruction: 0.627 +graphic: 0.623 +network: 0.619 +assembly: 0.618 +semantic: 0.611 +device: 0.599 +socket: 0.591 + +drive-backup with iscsi, it will failed "Could not create image: Invalid argument" + +I use iscsi protocol to drive-backup: + +---iscsi target--- +yum -y install targetcli python-rtslib +systemctl start target +systemctl enable target +targetcli /iscsi create iqn.2019-01.com.iaas +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.1 3260 +targetcli /backstores/fileio create file1 /opt/file1 2G +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/file1 +------------------- + +Now, '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.1:3260/iqn.2019-01.com.iaas/0" } }' + +It may failed: {"id":"libvirt-1785","error":{"class":"GenericError","desc":"Could not create image: Invalid argument"}} + +But, This abnormal will be appear at the first time. Because when I retry again, It works very well. + +Then, I re-start the vm, It still be failed 'Could not create image: Invalid argument' on the first try, and the second try it will work very well. + +--- +Host: centos 7.5 +qemu version: 2.12 and 3.1.0 +qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +Hi, qemu version 3.1 is a bit old in terms of upstream support. Can you confirm that this is still an issue on 4.2 ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1821771 b/results/classifier/105/KVM/1821771 new file mode 100644 index 00000000..677c6ef4 --- /dev/null +++ b/results/classifier/105/KVM/1821771 @@ -0,0 +1,103 @@ +KVM: 0.943 +boot: 0.921 +other: 0.905 +mistranslation: 0.902 +instruction: 0.890 +device: 0.873 +assembly: 0.868 +graphic: 0.866 +semantic: 0.863 +socket: 0.862 +network: 0.860 +vnc: 0.850 + +KVM guest does not reflect numa distances configured through qemu + +KVM guest does not reflect numa distances configured through qemu + +Env: +Host/Guest Kernel: 5.1.0-rc1-g72999bbdc +qemu : 3.1.90 (v2.8.0-rc0-18614-g278aebafa0-dirty) [repo: https://github.com/dgibson/qemu; branch:ppc-for-4.1 ] +# git log -1 +commit 278aebafa02f699857ca082d966bcbc05dc9bffb (HEAD -> ppc-for-4.1) +Author: Jafar Abdi <email address hidden> +Date: Sat Mar 23 17:26:36 2019 +0300 + + tests/libqos: fix usage of bool in pci-spapr.c + + Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. + + FALSE and TRUE (with capital letters) are the constants defined by glib for + being used with the "gboolean" type of glib. But some parts of the code also use + TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). + + Signed-off-by: Jafar Abdi <email address hidden> + Reviewed-by: Eric Blake <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: David Gibson <email address hidden> + +# libvirtd -V +libvirtd (libvirt) 5.1.0 + + + +Steps to reproduce: +1. Boot attached guest xml with predefined numa distance. + +qemu-commandline: +/usr/share/avocado-plugins-vt/bin/install_root/bin/qemu-system-ppc64 -name guest=vm2,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-vm2/master-key.aes -machine pseries-4.0,accel=kvm,usb=off,dump-guest-core=off -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -numa node,nodeid=0,cpus=0-1,mem=2048 -numa node,nodeid=1,cpus=2-3,mem=2048 -uuid 1a870f1d-269a-4a8c-84bc-2b5bda72823a -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=28,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/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0 -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-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=30,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f4:f5:f6,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + + +2. Check numa distance and other details inside guest +# numactl -H +available: 2 nodes (0-1) +node 0 cpus: 0 1 +node 0 size: 2025 MB +node 0 free: 1837 MB +node 1 cpus: 2 3 +node 1 size: 2045 MB +node 1 free: 1646 MB +node distances: +node 0 1 + 0: 10 40 -----------------------------------NOK + 1: 40 10 + +# lsprop /proc/device-tree/cpus/PowerPC\,POWER9\@*/ibm\,associativity +/proc/device-tree/cpus/PowerPC,POWER8@0/ibm,associativity + 00000005 00000000 00000000 00000000 00000000 00000000 +/proc/device-tree/cpus/PowerPC,POWER8@10/ibm,associativity + 00000005 00000000 00000000 00000000 00000001 00000010 +/proc/device-tree/cpus/PowerPC,POWER8@18/ibm,associativity + 00000005 00000000 00000000 00000000 00000001 00000018 +/proc/device-tree/cpus/PowerPC,POWER8@8/ibm,associativity + 00000005 00000000 00000000 00000000 00000000 00000008 + +# lsprop /proc/device-tree/rtas/ibm,associativity-reference-points +/proc/device-tree/rtas/ibm,associativity-reference-points + 00000004 00000004 + +Expected numa distances: +node distances: +node 0 1 + 0: 10 20 + 1: 20 10 + + + +Documentation describing the current qemu behaviour is captured here, https://<email address hidden>/msg726442.html + +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/105/KVM/1830821 b/results/classifier/105/KVM/1830821 new file mode 100644 index 00000000..b7a0e4c7 --- /dev/null +++ b/results/classifier/105/KVM/1830821 @@ -0,0 +1,47 @@ +KVM: 0.819 +device: 0.514 +graphic: 0.514 +network: 0.458 +semantic: 0.411 +socket: 0.398 +vnc: 0.361 +boot: 0.345 +mistranslation: 0.287 +instruction: 0.283 +other: 0.160 +assembly: 0.150 + +Expose ARCH_CAP_MDS_NO in guest + +Description: + +MDS_NO is bit 5 of ARCH_CAPABILITIES. Expose this bit to guest. + +Target Qemu: 4.1 + +The specific upstream commit is 20140a82c67467f53814ca197403d5e1b561a5e5 and is incorporated into qemu 1:3.1+dfsg-2ubuntu3.1 in disco-security (19.04) and 1:3.1+dfsg-2ubuntu4 in eoan-proposed. For backporting to cosmic and older, I believe it requires the infrastructure to support IA32_ARCH_CAPABILITIES in place. + +This is done upstream, no need for the upstream bug task. +For Ubuntu I'll update the tasks to match the statement of sbeattie. +There are discussions to reconsider some of the backports, but unfortunately the IA32_ARCH_CAPABILITIES infrastructure is a rather big set of changes. + +This effort, if done, would be done together with: + +https://bugs.launchpad.net/intel/+bug/1828495 + +Please read comments: + +https://bugs.launchpad.net/intel/+bug/1828495/comments/8 + +and + +https://bugs.launchpad.net/intel/+bug/1828495/comments/10 + +I'm marking this bug as a duplicate of LP: #1828495 since both are asking for mitigations pass-through to i386 kvm guests and I'm preparing a fix for both simultaneously. + +Commit: + +https://bugs.launchpad.net/intel/+bug/1828495/comments/42 + +Addresses exactly this bug fix. + diff --git a/results/classifier/105/KVM/1833204 b/results/classifier/105/KVM/1833204 new file mode 100644 index 00000000..fabe4c98 --- /dev/null +++ b/results/classifier/105/KVM/1833204 @@ -0,0 +1,137 @@ +KVM: 0.860 +mistranslation: 0.853 +other: 0.851 +vnc: 0.827 +device: 0.769 +graphic: 0.739 +semantic: 0.727 +instruction: 0.704 +boot: 0.690 +socket: 0.655 +assembly: 0.638 +network: 0.629 + +VM failed to start in nested virtualization with error "KVM: entry failed, hardware error 0x0" + +Hi, + +I have 3 ubuntu nodes provisioned by IaaS. +Then I tried to launch VM again in my ubuntu nodes. +It's a little strange that VM could be started successfully in two nodes. +And always failed in one nodes with error "KVM: entry failed, hardware error 0x0". + +When using virsh to resume the VM, it failed with following error, +virsh # list + Id Name State +---------------------------------- + 1 default_vm-cirros paused + +virsh # resume default_vm-cirros +error: Failed to resume domain default_vm-cirros +error: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + + +The detailed log from /var/log/libvirt/qemu/default_vm-cirros.log is as below. +``` +2019-06-18 09:55:52.397+0000: starting up libvirt version: 5.0.0, package: 1.fc28 (Unknown, 2019-01-22-08:04:34, 64723eea657e48d296e6beb0b1be9c4c), qemu version: 3.1.0qemu-3.1.0-4.fc28, kernel: 4.15.0-47-generic, hostname: vm-cirros +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ +HOME=/root \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=default_vm-cirros,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_vm-cirros/master-key.aes \ +-machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,mpx=on,avx512f=on,avx512cd=on,ssbd=on,xsaveopt=on,abm=on,invpcid=off \ +-m 489 \ +-realtime mlock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-object iothread,id=iothread1 \ +-uuid 0d2a2043-41c0-59c3-9b17-025022203668 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=22,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \ +-drive file=/var/run/kubevirt-ephemeral-disks/container-disk-data/default/vm-cirros/disk_containerdisk/disk-image.raw,format=raw,if=none,id=drive-ua-containerdisk,cache=none \ +-device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-ua-containerdisk,id=ua-containerdisk,bootindex=1,write-cache=on \ +-drive file=/var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-cirros/noCloud.iso,format=raw,if=none,id=drive-ua-cloudinitdisk,cache=none \ +-device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-ua-cloudinitdisk,id=ua-cloudinitdisk,write-cache=on \ +-netdev tap,fd=24,id=hostua-default,vhost=on,vhostfd=25 \ +-device virtio-net-pci,host_mtu=1430,netdev=hostua-default,id=ua-default,mac=16:57:38:cd:57:cb,bus=pci.1,addr=0x0 \ +-chardev socket,id=charserial0,fd=26,server,nowait \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,fd=27,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-vnc vnc=unix:/var/run/kubevirt-private/3b22a138-91af-11e9-af36-0016ac101123/virt-vnc \ +-device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +KVM: entry failed, hardware error 0x0 +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306d2 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=06 66 05 00 00 01 00 8e c1 26 66 a3 14 f5 66 5b 66 5e 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +Ubuntu node version as follow, +cat /etc/os-release +NAME="Ubuntu" +VERSION="18.04.2 LTS (Bionic Beaver)" +ID=ubuntu +ID_LIKE=debian +PRETTY_NAME="Ubuntu 18.04.2 LTS" +VERSION_ID="18.04" +HOME_URL="https://www.ubuntu.com/" +SUPPORT_URL="https://help.ubuntu.com/" +BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" +PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" +VERSION_CODENAME=bionic +UBUNTU_CODENAME=bionic + +Output of `uname -a` is: +4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux + + + +Any additional information needed, please let me know. +Thx. + +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/105/KVM/1834051 b/results/classifier/105/KVM/1834051 new file mode 100644 index 00000000..e603b340 --- /dev/null +++ b/results/classifier/105/KVM/1834051 @@ -0,0 +1,40 @@ +KVM: 0.947 +device: 0.656 +other: 0.630 +semantic: 0.627 +graphic: 0.621 +instruction: 0.614 +network: 0.578 +socket: 0.552 +mistranslation: 0.544 +vnc: 0.454 +boot: 0.371 +assembly: 0.344 + +IRQ2 ignored under KVM when using IOAPIC + +When using KVM, and an OS that supports the IOAPIC, interrupts mapped on IRQ2 (for instance, routing an HPET timer on interrupt 2) will cause the interrupts to never be delivered. This is because QEmu, when setting up the KVM interrupt routes, will not set one up for IRQ2[0]. When running without KVM, IRQ2 is identity-mapped to GSI2. + +My understanding is that IRQs should be identity mapped to their equivalent GSI unless a redirection entry is present in the MADT. This is supported by ACPI 6.2 spec[1], 5.2.12.5 Interrupt Source Override Structure, which claims: "It is assumed that the ISA interrupts will be identity-mapped into the first I/O APIC sources.". + +I stumbled across this while working on my own custom OS, got very confused why the HPET wasn't triggering any interruption - and even more confused why the behavior only happened in KVM and not in non-KVM. + +[0]: https://github.com/qemu/qemu/blob/37560c259d7a0d6aceb96e9d6903ee002f4e5e0c/hw/i386/kvm/ioapic.c#L40 + +[1]: https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf + +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/105/KVM/1835466 b/results/classifier/105/KVM/1835466 new file mode 100644 index 00000000..f645ae77 --- /dev/null +++ b/results/classifier/105/KVM/1835466 @@ -0,0 +1,263 @@ +KVM: 0.872 +vnc: 0.850 +other: 0.824 +mistranslation: 0.773 +graphic: 0.737 +device: 0.732 +semantic: 0.702 +instruction: 0.700 +assembly: 0.688 +socket: 0.687 +network: 0.676 +boot: 0.633 + +qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?) + +After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release tarball), I'm seeing a (reproducible) crash related to audio subsystem. + +I recompiled qemu with debugging options and got it to crash under gdb: + +Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted. +0x00007ffff52e420b in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff52e420b in raise () at /lib64/libc.so.6 +#1 0x00007ffff52c6524 in abort () at /lib64/libc.so.6 +#2 0x000000000041ec33 in audio_get_pdo_in (dev=<optimized out>) at audio/audio_template.h:328 +#3 0x00000000005d0123 in AUD_open_in + (card=0x7ffdde98dbc8, sw=0x7ffff17444e0, name=0x999d80 "adc", callback_opaque=callback_opaque@entry=0x7ffdde98fd58, callback_fn=0x610940 <hda_audio_input_cb>, as=as@entry=0x7ffdde98fd84) at audio/audio_template.h:434 +#4 0x000000000060fe2e in hda_audio_setup (st=0x7ffdde98fd58) at hw/audio/hda-codec.c:490 +#5 0x000000000061051b in hda_audio_command (hda=0x7ffdde98db40, nid=4, data=<optimized out>) at hw/audio/hda-codec.c:590 +#6 0x000000000060ea20 in intel_hda_send_command (d=d@entry=0x7ffff0a2fc00, verb=verb@entry=4341777) at hw/audio/intel-hda.c:301 +#7 0x000000000060ebbe in intel_hda_corb_run (d=<optimized out>) at hw/audio/intel-hda.c:336 +#8 0x000000000060ebbe in intel_hda_corb_run (d=0x7ffff0a2fc00) at hw/audio/intel-hda.c:305 +#9 0x0000000000495b99 in memory_region_write_accessor + (mr=mr@entry=0x7ffff0a307a0, addr=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, shift=<optimized out>, mask=mask@entry=65535, attrs=...) + at memory.c:502 +#10 0x000000000049448e in access_with_adjusted_size + (addr=addr@entry=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x495b10 <memory_region_write_accessor>, mr=0x7ffff0a307a0, attrs=...) at memory.c:568 +#11 0x00000000004974f3 in memory_region_dispatch_write (mr=mr@entry=0x7ffff0a307a0, addr=72, data=<optimized out>, size=2, attrs=attrs@entry=...) + at memory.c:1496 +#12 0x000000000042afbc in flatview_write_continue + (fv=fv@entry=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x7ffff0a307a0) at exec.c:3279 +#13 0x000000000042b1d6 in flatview_write + (fv=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2) + at exec.c:3318 +#14 0x000000000042e2a6 in address_space_write + (as=0xfc5080 <address_space_memory>, addr=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=2) + at exec.c:3408 +#15 0x000000000042e33a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., + attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=<optimized out>, is_write=<optimized out>) at exec.c:3419 +#16 0x00000000004ac3c6 in kvm_cpu_exec (cpu=cpu@entry=0x7ffff0a81140) at accel/kvm/kvm-all.c:2034 +#17 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=0x7ffff0a81140) at cpus.c:1281 +#18 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x7ffff0a81140) at cpus.c:1254 +#19 0x000000000089d0eb in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:502 +#20 0x00007ffff549319c in start_thread () at /lib64/libpthread.so.0 +#21 0x00007ffff53ba4af in clone () at /lib64/libc.so.6 + + +After some poking around, I think there's something overwriting dev->driver so this switch(dev->driver) statement falls through to abort(): https://git.qemu.org/?p=qemu.git;a=blob;f=audio/audio_template.h;h=1232bb54db0e7073e60e3ccb72c1ed72cf5e3831;hb=131b9a05705636086699df15d4a6d328bb2585e8#l304 + + +Here's why I think so: + +$ export QEMU_AUDIO_DRV=pa +$ gdb /usr/bin/qemu-system-x86_64 +(gdb) b qpa_audio_init +Breakpoint 1 at 0x79bcb0: file audio/paaudio.c, line 831. +(gdb) b audio_get_pdo_in +Breakpoint 2 at 0x5ce320: file audio/audio_template.h, line 304. +(gdb) run -enable-kvm -cpu Nehalem -machine q35 -device intel-iommu -name Workstation -smp 4 -m 8G -soundhw hda -rtc base=localtime -drive file=workstation-disk0.qcow2,if=virtio,format=qcow2 -drive file=workstation-disk1.qcow2,if=virtio,format=qcow2 -net nic,model=virtio,macaddr=aa:bb:cc:dd:ee:ff -net tap,ifname=tap42 -monitor telnet:127.0.0.1:7043,server,nowait -pidfile workstation.pid -vga qxl -global qxl-vga.vgamem_mb=64 -device usb-ehci,id=ehci -device usb-host,vendorid=0x1390,productid=0x5454,bus=ehci.0 -device usb-host,vendorid=0x054c,bus=ehci.0 -device usb-tablet -device nec-usb-xhci,id=xhci -device usb-host,vendorid=0x10c4,productid=0x888e,bus=xhci.0 + +Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831 +(gdb) p (*dev)->driver +$1 = AUDIODEV_DRIVER_PA +(gdb) p/d AUDIODEV_DRIVER_PA +$2 = 5 +(gdb) cont +Continuing. +[Thread 0x7ffff09ff700 (LWP 4078) exited] +audio: warning: Using timer based audio emulation +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$3 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$4 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$5 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. +[New Thread 0x7ffff09ff700 (LWP 4483)] +[New Thread 0x7ffddcdff700 (LWP 4489)] +[New Thread 0x7ffddbdff700 (LWP 4490)] +[New Thread 0x7ffddb1ff700 (LWP 4491)] +[New Thread 0x7ffdd2dff700 (LWP 4494)] +[New Thread 0x7ffdd25fe700 (LWP 4495)] +[New Thread 0x7ffdd1dfd700 (LWP 4497)] +[New Thread 0x7ffdda5ff700 (LWP 4500)] +[New Thread 0x7ffdcedff700 (LWP 4501)] +qemu-system-x86_64: warning: guest updated active QH +[Switching to Thread 0x7fffef7ff700 (LWP 4097)] + +Thread 4 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$6 = 176 + + +For what it's worth, guest is Fedora 29, host is a Slackware system with qemu compiled (manually) with these options: + +CFLAGS="-O2 -fPIC" \ +CXXFLAGS="-O2 -fPIC" \ +./configure \ + --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var \ + --enable-gtk \ + --enable-system \ + --enable-kvm \ + --enable-virtfs \ + --enable-sdl \ + --enable-gnutls \ + --enable-curses \ + --enable-virtfs \ + --enable-curl \ + --enable-linux-aio \ + --enable-vhost-net \ + --enable-spice \ + --enable-libusb \ + --enable-usb-redir \ + --enable-lzo \ + --enable-bzip2 \ + --enable-libssh2 \ + --enable-numa \ + --enable-jemalloc \ + --enable-opengl \ + --audio-drv-list=alsa,oss,sdl,pa \ + --enable-vnc --enable-vnc-sasl --enable-vnc-png --enable-vnc-jpeg \ + --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user,arm-softmmu,arm-linux-user,armeb-linux-user,sparc64-softmmu,sparc-softmmu,sparc32plus-linux-user,sparc64-linux-user \ + --enable-debug --extra-cflags="-g3" --extra-ldflags="-g3" --disable-strip --disable-pie # For debugging only + +Can you set a watchpoint for (*dev)->driver and see where it fires? + +My gdb-fu isn't great - does the following help? + + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 audio/audio_template.h: No such file or directory. +(gdb) print (*dev)->driver +$1 = AUDIODEV_DRIVER_PA +(gdb) watch *0x7ffff161b6a0 +Hardware watchpoint 4: *0x7ffff161b6a0 +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831 +831 audio/paaudio.c: No such file or directory. +(gdb) cont +Continuing. +audio: warning: Using timer based audio emulation + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 audio/audio_template.h: No such file or directory. +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) p (*dev)->driver +$2 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. +[New Thread 0x7ffff09ff700 (LWP 6438)] +[New Thread 0x7ffddcdff700 (LWP 6439)] + +Thread 1 "qemu-system-x86" hit Hardware watchpoint 4: *0x7ffff161b6a0 + +Old value = -486628296 +New value = 0 +0x00007ffff5422cf0 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff5422cf0 in __memset_avx2_unaligned_erms () at /lib64/libc.so.6 +#1 0x00007ffff580cee3 in calloc () at /usr/lib64/libjemalloc.so.2 +#2 0x00007ffff7ac9db1 in g_malloc0 () at /usr/lib64/libglib-2.0.so.0 +#3 0x00007ffff7bc7cc9 in () at /usr/lib64/libgobject-2.0.so.0 +#4 0x00007ffff7bca8b8 in g_type_register_static () at /usr/lib64/libgobject-2.0.so.0 +#5 0x00007ffff7bca94d in g_type_register_static_simple () at /usr/lib64/libgobject-2.0.so.0 +#6 0x00007ffff7040e3a in () at /usr/lib64/libgtk-3.so.0 +#7 0x00007ffff7043865 in gtk_icon_theme_get_type () at /usr/lib64/libgtk-3.so.0 +#8 0x00007ffff7043889 in gtk_icon_theme_new () at /usr/lib64/libgtk-3.so.0 +#9 0x00007ffff7043aa5 in gtk_icon_theme_get_for_screen () at /usr/lib64/libgtk-3.so.0 +#10 0x00000000007a0df3 in gtk_display_init (ds=<optimized out>, opts=0xfe7ae0 <dpy>) at ui/gtk.c:2200 +#11 0x0000000000423dd8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4532 +(gdb) +(gdb) cont +Continuing. +[Thread 0x7ffddcdff700 (LWP 6439) exited] + +Thread 1 "qemu-system-x86" hit Hardware watchpoint 4: *0x7ffff161b6a0 + +Old value = 0 +New value = -245161264 +0x00007ffff7bc7de1 in ?? () from /usr/lib64/libgobject-2.0.so.0 +(gdb) cont +Continuing. +[New Thread 0x7ffddcdff700 (LWP 6507)] +[New Thread 0x7ffddbbff700 (LWP 6508)] +[New Thread 0x7ffdd85ff700 (LWP 6509)] +[New Thread 0x7ffdd25ff700 (LWP 6510)] +[New Thread 0x7ffdd1dfe700 (LWP 6511)] +[New Thread 0x7ffdd15fd700 (LWP 6512)] +[New Thread 0x7ffddaafa700 (LWP 6513)] +[New Thread 0x7ffdce7ff700 (LWP 6514)] +[New Thread 0x7ffdcdbff700 (LWP 6515)] +qemu-system-x86_64: warning: guest updated active QH +[Switching to Thread 0x7fffee9ff700 (LWP 6340)] + +Thread 5 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) + at audio/audio_template.h:304 +304 in audio/audio_template.h +(gdb) print (*dev)->driver +$3 = 176 + + +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/105/KVM/1836763 b/results/classifier/105/KVM/1836763 new file mode 100644 index 00000000..5098360c --- /dev/null +++ b/results/classifier/105/KVM/1836763 @@ -0,0 +1,132 @@ +KVM: 0.596 +graphic: 0.552 +instruction: 0.513 +device: 0.493 +assembly: 0.480 +network: 0.478 +boot: 0.465 +vnc: 0.460 +other: 0.445 +mistranslation: 0.441 +socket: 0.375 +semantic: 0.361 + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error + +Trying to use the Firebird database on qemu-m68k-user with a Debian chroot fails with the database crashing with "ConfigStorage: mutex pthread_mutex_init error, status = 95": + +(sid-m68k-sbuild)root@epyc:/# apt install firebird3.0-server +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages were automatically installed and are no longer required: + cpio libip4tc0 +Use 'apt autoremove' to remove them. +The following additional packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +Suggested packages: + firebird3.0-doc +The following NEW packages will be installed: + firebird3.0-common firebird3.0-common-doc firebird3.0-server firebird3.0-server-core firebird3.0-utils libfbclient2 libib-util +0 upgraded, 7 newly installed, 0 to remove and 4 not upgraded. +Need to get 4,051 kB of archives. +After this operation, 15.9 MB of additional disk space will be used. +Do you want to continue? [Y/n] +Get:1 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common-doc all 3.0.5.33100.ds4-3 [35.3 kB] +Get:2 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-common all 3.0.5.33100.ds4-3 [14.5 kB] +Get:3 http://ftp.ports.debian.org/debian-ports unstable/main m68k libfbclient2 m68k 3.0.5.33100.ds4-3 [496 kB] +Get:4 http://ftp.ports.debian.org/debian-ports unstable/main m68k libib-util m68k 3.0.5.33100.ds4-3 [3,220 B] +Get:5 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server-core m68k 3.0.5.33100.ds4-3 [2,368 kB] +Get:6 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-utils m68k 3.0.5.33100.ds4-3 [770 kB] +Get:7 http://ftp.ports.debian.org/debian-ports unstable/main m68k firebird3.0-server m68k 3.0.5.33100.ds4-3 [365 kB] +Fetched 4,051 kB in 2s (1,803 kB/s) +debconf: delaying package configuration, since apt-utils is not installed +E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) +Selecting previously unselected package firebird3.0-common-doc. +(Reading database ... 33605 files and directories currently installed.) +Preparing to unpack .../0-firebird3.0-common-doc_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-common. +Preparing to unpack .../1-firebird3.0-common_3.0.5.33100.ds4-3_all.deb ... +Unpacking firebird3.0-common (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libfbclient2:m68k. +Preparing to unpack .../2-libfbclient2_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package libib-util:m68k. +Preparing to unpack .../3-libib-util_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking libib-util:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server-core:m68k. +Preparing to unpack .../4-firebird3.0-server-core_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-utils. +Preparing to unpack .../5-firebird3.0-utils_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-utils (3.0.5.33100.ds4-3) ... +Selecting previously unselected package firebird3.0-server. +Preparing to unpack .../6-firebird3.0-server_3.0.5.33100.ds4-3_m68k.deb ... +Unpacking firebird3.0-server (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common-doc (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-common (3.0.5.33100.ds4-3) ... +Setting up libib-util:m68k (3.0.5.33100.ds4-3) ... +Setting up libfbclient2:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-utils (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server-core:m68k (3.0.5.33100.ds4-3) ... +Setting up firebird3.0-server (3.0.5.33100.ds4-3) ... +debconf: unable to initialize frontend: Dialog +debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) +debconf: falling back to frontend: Readline +Password for firebird 3.0 +------------------------- + +Firebird has a special user named SYSDBA, which is the user that has access to all databases. SYSDBA can also create new databases and users. Because of this, it is +necessary to secure SYSDBA with a password. + +The password is stored in /etc/firebird/3.0/SYSDBA.password (readable only by root). You may modify it there (don't forget to update the security database too, using the +gsec utility), or you may use dpkg-reconfigure to update both. + +If you don't enter a password, a random one will be used (and stored in SYSDBA.password). + +Password for SYSDBA: + +adduser: Warning: The home directory `/var/lib/firebird' does not belong to the user you are currently creating. +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +dpkg: error processing package firebird3.0-server (--configure): + installed firebird3.0-server package post-installation script subprocess returned error exit status 134 +Processing triggers for systemd (241-6+b2) ... +Processing triggers for man-db (2.8.5-2) ... +Not building database; man-db/auto-update is not 'true'. +Processing triggers for libc-bin (2.28-10+qemu) ... +Errors were encountered while processing: + firebird3.0-server +E: Sub-process /usr/bin/dpkg returned an error code (1) +(sid-m68k-sbuild)root@epyc:/# SEC_SQL=/usr/share/firebird/3.0/security.sql T=/tmp/tmp.2kBDCgAevm T_SEC=/tmp/tmp.2kBDCgAevm/security.fdb isql-fb -q +SQL> create database '/tmp/tmp.2kBDCgAevm/security.fdb'; +ConfigStorage: mutex pthread_mutex_init error, status = 95 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-m68k-sbuild)root@epyc:/# + +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.] + + +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/442 + + diff --git a/results/classifier/105/KVM/1838569 b/results/classifier/105/KVM/1838569 new file mode 100644 index 00000000..0210d10a --- /dev/null +++ b/results/classifier/105/KVM/1838569 @@ -0,0 +1,111 @@ +KVM: 0.691 +mistranslation: 0.644 +device: 0.625 +assembly: 0.604 +graphic: 0.602 +vnc: 0.592 +network: 0.570 +boot: 0.564 +instruction: 0.556 +other: 0.532 +semantic: 0.478 +socket: 0.451 + +virtio-balloon change breaks post 4.0 upgrade + +We upgraded the libvirt UCA packages from 3.6 to 4.0 as part of a queens upgrade and noticed that +virtio-ballon is broken when instances live migrate (started with a prior 3.6 version) with: + + +2019-07-24T06:46:49.487109Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control +2019-07-24T06:47:22.187749Z qemu-system-x86_64: VQ 2 size 0x80 < last_avail_idx 0xb57 - used_idx 0xb59 +2019-07-24T06:47:22.187768Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2019-07-24T06:47:22.187771Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' +2019-07-24T06:47:22.188194Z qemu-system-x86_64: load of migration failed: Operation not permitted +2019-07-24 06:47:22.430+0000: shutting down, reason=failed + +This seem to be the exact problem as reported by https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02228.html + +Listed the packages which changed: + +Start-Date: 2019-07-06 06:40:55 +Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install libvirt-bin python-libvirt qemu qemu-utils qemu-system qemu-system-arm qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-system-misc qemu-block-extra qemu-utils qemu-user qemu-kvm +Install: librdmacm1:amd64 (17.1-1ubuntu0.1~cloud0, automatic), libvirt-daemon-driver-storage-rbd:amd64 (4.0.0-1ubuntu8.10~cloud0, automatic), ipxe-qemu-256k-compat-efi-roms:amd64 (1.0.0+git-20150424.a25a16d-0ubuntu2~cloud0, automatic) +Upgrade: qemu-system-mips:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-misc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-ppc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), python-libvirt:amd64 (3.5.0-1build1~cloud0, 4.0.0-1~cloud0), qemu-system-x86:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-clients:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-user:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-bin:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-utils:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon-system:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-sparc:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-user-binfmt:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-kvm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt0:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0), qemu-system-arm:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-block-extra:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system-common:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), qemu-system:amd64 (1:2.10+dfsg-0ubuntu3.8~cloud1, 1:2.11+dfsg-1ubuntu7.13~cloud0), libvirt-daemon:amd64 (3.6.0-1ubuntu6.8~cloud0, 4.0.0-1ubuntu8.10~cloud0) +End-Date: 2019-07-06 06:41:08 + +At this point the instances would have to be hard rebooted or stopped/started to fix the issue for future live migration attemps + +Hi Bjoern, + I don't think this is the same bug as the one you reference; that's a config space disagreement, not a virtio queue disagreeement. + +It almost feels like the old 4a1e48becab81020adfb74b22c76a595f2d02a01 stats migration fix; but that went in with 2.8 so shouldn't be a problem going 2.10 to 2.11 + + +In regard to "similar bugs" it sounds more like [1] to me. +Which was around needing [2]. + +But just like the commit David mentioned is in 2.8 this one is in since 2.6 (and backported). + +[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389 +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=4eae2a657d1ff5ada56eb9b4966eae0eff333b0b + +Status changed to 'Confirmed' because the bug affects multiple users. + +With recent release of OpenStack Train this issue reappears... + +Upgrading from Stein to Train will require all VMs to be hard-rebooted to be migrated as a final step because Live Migration fails with: + +Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd[1545]: Unable to read from monitor: Connection reset by peer +Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd[1545]: internal error: qemu unexpectedly closed the monitor: 2019-10-17T10:28:42.981201Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0 + 2019-10-17T10:28:42.981250Z qemu-system-x86_64: Failed to load PCIDevice:config + 2019-10-17T10:28:42.981263Z qemu-system-x86_64: Failed to load virtio-balloon:virtio + 2019-10-17T10:28:42.981272Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon' + 2019-10-17T10:28:42.981391Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable + 2019-10-17T10:28:42.983157Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable + 2019-10-17T10:28:42.983672Z qemu-system-x86_64: load of migration failed: Invalid argument + + +Dnaiel: That's a different problem; 'Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0'; so should probably be a separate bug. + +I'd bet on this being the one fixed by 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +> I'd bet on this being the one fixed by +> 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +But wasn't the breakage this fixes only added in qemu 4.0? +He reports his change is from qemu 2.10 to 2.11. + +Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has +something backported that makes the Ubuntu 2.11 being affected by it. +I checked the Delta but there was nothing related backported that I +could identify. + +But I agree, that first of all this should be a new bug instead of +reviving the old one here. + + +> I'd bet on this being the one fixed by +> 2bbadb08ce272d65e1f78621002008b07d1e0f03 + +But wasn't the breakage this fixes only added in qemu 4.0? +He reports his change is from qemu 2.10 to 2.11. + +Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has +something backported that makes the Ubuntu 2.11 being affected by it. +I checked the Delta but there was nothing related backported that I +could identify. + +But I agree, that first of all this should be a new bug instead of +reviving the old one here. + +P.S. this will race as I sent the same via mail :-/, but I need to extend. + +I have now realized that the later report (comment #4) is about Openstack Train which at least on Ubuntu would come with qemu 4.0 - and since 2bbadb08 was released only with 4.1 that would be an open issue. + + +I forked that new discussion into https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497 +Please follow there and leave this bug here to the originally reported error signature. + +It seems the fix is comitted with https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497. Closing this issue + diff --git a/results/classifier/105/KVM/1843073 b/results/classifier/105/KVM/1843073 new file mode 100644 index 00000000..60f3be18 --- /dev/null +++ b/results/classifier/105/KVM/1843073 @@ -0,0 +1,225 @@ +KVM: 0.931 +other: 0.927 +vnc: 0.925 +network: 0.917 +assembly: 0.904 +mistranslation: 0.894 +graphic: 0.887 +semantic: 0.885 +device: 0.884 +instruction: 0.882 +boot: 0.879 +socket: 0.874 + +Network loose connection for long time under light load guest winxp64 with virtio on i5-8350U + +I have issue with qemu and winxp guest on i5-8350U. + +First of all, if i run same vm with same config on i5 9660k i do not see such issue. +Both pc have ubuntu 19.04 x86_64. + +Guest is winxp64, tried: +1) stable guest drivers, latest drivers +2) all virtio, only network r18169, bridge to host eth0, just default virbr0. +3) qemu from ubuntu 19.04, and tried latest libvirt and qeumu compiled from sources. +4) tried zram as block device + +I need really lightweight win to run only one app, so win7 and win10 is not an option. + + +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit winxp +or other application using the libvirt API. +--> + +<domain type='kvm'> + <name>winxp</name> + <uuid>93921ab3-222a-4e5f-89c4-36703fc65cb4</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://microsoft.com/win/xp"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>8388608</memory> + <currentMemory unit='KiB'>8388608</currentMemory> + <vcpu placement='static'>4</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='2'/> + <vcpupin vcpu='1' cpuset='3'/> + <vcpupin vcpu='2' cpuset='6'/> + <vcpupin vcpu='3' cpuset='7'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-i440fx-4.1'>hvm</type> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + <vpindex state='on'/> + <synic state='on'/> + <stimer state='on'/> + </hyperv> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/zram0'/> + <target dev='vdb' bus='virtio'/> + <shareable/> + <boot order='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/virtio-win.iso'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d1:b3:87'/> + <source network='default'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' port='5900' autoport='no' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + <image compression='auto_glz'/> + <jpeg compression='auto'/> + <zlib compression='auto'/> + <playback compression='off'/> + <streaming mode='off'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> +</domain> + +Ping at the load moment: + ping 192.168.152.25 +PING 192.168.152.25 (192.168.152.25) 56(84) bytes of data. +64 bytes from 192.168.152.25: icmp_seq=1 ttl=128 time=0.300 ms +64 bytes from 192.168.152.25: icmp_seq=2 ttl=128 time=0.495 ms +64 bytes from 192.168.152.25: icmp_seq=3 ttl=128 time=0.442 ms +64 bytes from 192.168.152.25: icmp_seq=4 ttl=128 time=0.520 ms +64 bytes from 192.168.152.25: icmp_seq=5 ttl=128 time=0.558 ms +64 bytes from 192.168.152.25: icmp_seq=6 ttl=128 time=0.623 ms +64 bytes from 192.168.152.25: icmp_seq=7 ttl=128 time=0.668 ms +64 bytes from 192.168.152.25: icmp_seq=8 ttl=128 time=0.574 ms +64 bytes from 192.168.152.25: icmp_seq=9 ttl=128 time=0.390 ms +64 bytes from 192.168.152.25: icmp_seq=10 ttl=128 time=363 ms +From 192.168.152.1 icmp_seq=29 Destination Host Unreachable +From 192.168.152.1 icmp_seq=30 Destination Host Unreachable +From 192.168.152.1 icmp_seq=31 Destination Host Unreachable +From 192.168.152.1 icmp_seq=32 Destination Host Unreachable +From 192.168.152.1 icmp_seq=33 Destination Host Unreachable +From 192.168.152.1 icmp_seq=34 Destination Host Unreachable +From 192.168.152.1 icmp_seq=36 Destination Host Unreachable +From 192.168.152.1 icmp_seq=39 Destination Host Unreachable +From 192.168.152.1 icmp_seq=40 Destination Host Unreachable +64 bytes from 192.168.152.25: icmp_seq=11 ttl=128 time=33151 ms +64 bytes from 192.168.152.25: icmp_seq=12 ttl=128 time=32137 ms +From 192.168.152.1 icmp_seq=41 Destination Host Unreachable +From 192.168.152.1 icmp_seq=42 Destination Host Unreachable +From 192.168.152.1 icmp_seq=43 Destination Host Unreachable +From 192.168.152.1 icmp_seq=44 Destination Host Unreachable +From 192.168.152.1 icmp_seq=45 Destination Host Unreachable +From 192.168.152.1 icmp_seq=46 Destination Host Unreachable +From 192.168.152.1 icmp_seq=47 Destination Host Unreachable +From 192.168.152.1 icmp_seq=48 Destination Host Unreachable +From 192.168.152.1 icmp_seq=49 Destination Host Unreachable +From 192.168.152.1 icmp_seq=50 Destination Host Unreachable +64 bytes from 192.168.152.25: icmp_seq=13 ttl=128 time=39259 ms +64 bytes from 192.168.152.25: icmp_seq=14 ttl=128 time=38235 ms +64 bytes from 192.168.152.25: icmp_seq=15 ttl=128 time=37211 ms +64 bytes from 192.168.152.25: icmp_seq=16 ttl=128 time=36187 ms +64 bytes from 192.168.152.25: icmp_seq=17 ttl=128 time=35163 ms +64 bytes from 192.168.152.25: icmp_seq=18 ttl=128 time=34139 ms +64 bytes from 192.168.152.25: icmp_seq=19 ttl=128 time=33115 ms +64 bytes from 192.168.152.25: icmp_seq=20 ttl=128 time=32091 ms +64 bytes from 192.168.152.25: icmp_seq=21 ttl=128 time=31068 ms +64 bytes from 192.168.152.25: icmp_seq=22 ttl=128 time=30044 ms +64 bytes from 192.168.152.25: icmp_seq=23 ttl=128 time=29020 ms +64 bytes from 192.168.152.25: icmp_seq=24 ttl=128 time=27996 ms +64 bytes from 192.168.152.25: icmp_seq=25 ttl=128 time=26968 ms +64 bytes from 192.168.152.25: icmp_seq=26 ttl=128 time=25948 ms +64 bytes from 192.168.152.25: icmp_seq=27 ttl=128 time=24924 ms +64 bytes from 192.168.152.25: icmp_seq=28 ttl=128 time=23900 ms +64 bytes from 192.168.152.25: icmp_seq=51 ttl=128 time=412 ms +64 bytes from 192.168.152.25: icmp_seq=52 ttl=128 time=0.167 ms +64 bytes from 192.168.152.25: icmp_seq=53 ttl=128 time=0.559 ms +64 bytes from 192.168.152.25: icmp_seq=54 ttl=128 time=0.656 ms + + +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/105/KVM/1847440 b/results/classifier/105/KVM/1847440 new file mode 100644 index 00000000..ecf4f70e --- /dev/null +++ b/results/classifier/105/KVM/1847440 @@ -0,0 +1,562 @@ +KVM: 0.100 +device: 0.089 +other: 0.073 +semantic: 0.064 +boot: 0.063 +assembly: 0.063 +vnc: 0.061 +instruction: 0.060 +socket: 0.060 +network: 0.055 +graphic: 0.054 +mistranslation: 0.036 + +ppc64le: KVM guest fails to boot with an error `virtio_scsi: probe of virtio1 failed with error -22` on master + +PowerPC KVM Guest fails to boot on current qemu master(98b2e3c9ab3abfe476a2b02f8f51813edb90e72d), + +Env: +HW: IBM Power8 +Host Kernel: 5.4.0-rc2-00038-ge3280b54afed +Guest Kernel: 4.13.9-300.fc27.ppc64le +Qemu: https://github.com/qemu/qemu.git (master) +Libvirt: 5.4.0 + +Guest boot gets stuck: +... +[ OK ] Mounted Kernel Configuration File System. +[ 7.598740] virtio-pci 0000:00:01.0: enabling device (0000 -> 0003) +[ 7.598828] virtio-pci 0000:00:01.0: virtio_pci: leaving for legacy driver +[ 7.598957] virtio-pci 0000:00:02.0: enabling device (0000 -> 0003) +[ 7.599017] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver +[ 7.599123] virtio-pci 0000:00:04.0: enabling device (0000 -> 0003) +[ 7.599182] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver +[ 7.620620] synth uevent: /devices/vio: failed to send uevent +[ 7.620624] vio vio: uevent: failed to send synthetic uevent +[ OK ] Started udev Coldplug all Devices. +[ 7.624559] audit: type=1130 audit(1570610300.990:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ OK ] Reached target System Initialization. +[ OK ] Reached target Basic System. +[ OK ] Reached target Remote File Systems (Pre). +[ OK ] Reached target Remote File Systems. +[ 7.642961] virtio_scsi: probe of virtio1 failed with error -22 +[ *** ] A start job is running for dev-disk…21b3519a80.device (14s / no limit) +... + + + +git bisect, yielded a bad commit [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support, reverting this commit boot the guest properly. + +git bisect start +# good: [9e06029aea3b2eca1d5261352e695edc1e7d7b8b] Update version for v4.1.0 release +git bisect good 9e06029aea3b2eca1d5261352e695edc1e7d7b8b +# bad: [98b2e3c9ab3abfe476a2b02f8f51813edb90e72d] Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging +git bisect bad 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d +# good: [56e6250ede81b4e4b4ddb623874d6c3cdad4a96d] target/arm: Convert T16, nop hints +git bisect good 56e6250ede81b4e4b4ddb623874d6c3cdad4a96d +# good: [5d69cbdfdd5cd6dadc9f0c986899844a0e4de703] tests/tcg: target/s390x: Test MVC +git bisect good 5d69cbdfdd5cd6dadc9f0c986899844a0e4de703 +# good: [88112488cf228df8b7588c8aa38e16ecd0dff48e] qapi: Make check_type()'s array case a bit more obvious +git bisect good 88112488cf228df8b7588c8aa38e16ecd0dff48e +# good: [972bd57689f1e11311d86b290134ea2ed9c7c11e] ppc/kvm: Skip writing DPDES back when in run time state +git bisect good 972bd57689f1e11311d86b290134ea2ed9c7c11e +# bad: [1aba8716c8335e88b8c358002a6e1ac89f7dd258] ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine +git bisect bad 1aba8716c8335e88b8c358002a6e1ac89f7dd258 +# bad: [00ed3da9b5c2e66e796a172df3e19545462b9c90] xics: Minor fixes for XICSFabric interface +git bisect bad 00ed3da9b5c2e66e796a172df3e19545462b9c90 +# good: [33432d7737b53c92791f90ece5dbe3b7bb1c79f5] target/ppc: introduce set_dfp{64,128}() helper functions +git bisect good 33432d7737b53c92791f90ece5dbe3b7bb1c79f5 +# good: [f6d4c423a222f02bfa84a49c3d306d7341ec9bab] target/ppc: remove unnecessary if() around calls to set_dfp{64,128}() in DFP macros +git bisect good f6d4c423a222f02bfa84a49c3d306d7341ec9bab +# bad: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support +git bisect bad e68cd0cb5cf49d334abe17231a1d2c28b846afa2 +# good: [c4ec08ab70bab90685d1443d6da47293e3aa312a] spapr-pci: Stop providing assigned-addresses +git bisect good c4ec08ab70bab90685d1443d6da47293e3aa312a +# first bad commit: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support + + +attached vmxml. + +qemu commandline: +/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-19-vm1/master-key.aes -machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off -m 81920 -overcommit mem-lock=off -smp 512,sockets=1,cores=128,threads=4 -uuid fd4a5d54-0216-490e-82d2-1d4e89683b3d -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=24,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/sath/tests/data/avocado-vt/images/jeos-27-ppc64le_vm1.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=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:df:24,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -M pseries,ic-mode=xics -msg timestamp=on + + + +On Thu, Oct 10, 2019 at 07:16:49AM -0000, Launchpad Bug Tracker wrote: +> You have been subscribed to a public bug by Satheesh Rajendran (sathnaga): +> +> PowerPC KVM Guest fails to boot on current qemu master, bad commit: +> e68cd0cb5cf49d334abe17231a1d2c28b846afa2 +> +> Env: +> HW: IBM Power9 +> Host Kernel: 5.4.0-rc2-00038-ge3280b54afed +> Guest Kernel: 4.13.9-300.fc27.ppc64le +> Qemu: https://github.com/qemu/qemu.git (master) +> Libvirt: 5.4.0 +> +> Guest boot gets stuck: +> ... +> [ OK ] Mounted Kernel Configuration File System. +> [ 7.598740] virtio-pci 0000:00:01.0: enabling device (0000 -> 0003) +> [ 7.598828] virtio-pci 0000:00:01.0: virtio_pci: leaving for legacy driver +> [ 7.598957] virtio-pci 0000:00:02.0: enabling device (0000 -> 0003) +> [ 7.599017] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver +> [ 7.599123] virtio-pci 0000:00:04.0: enabling device (0000 -> 0003) +> [ 7.599182] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver +> [ 7.620620] synth uevent: /devices/vio: failed to send uevent +> [ 7.620624] vio vio: uevent: failed to send synthetic uevent +> [ OK ] Started udev Coldplug all Devices. +> [ 7.624559] audit: type=1130 audit(1570610300.990:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +> [ OK ] Reached target System Initialization. +> [ OK ] Reached target Basic System. +> [ OK ] Reached target Remote File Systems (Pre). +> [ OK ] Reached target Remote File Systems. +> [ 7.642961] virtio_scsi: probe of virtio1 failed with error -22 +> [ *** ] A start job is running for dev-disk…21b3519a80.device (14s / no limit) +> ... +> +> git bisect, yielded a bad commit +> [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm +> ,client-architecture-support, reverting this commit boot the guest +> properly. +> +> git bisect start +> # good: [9e06029aea3b2eca1d5261352e695edc1e7d7b8b] Update version for v4.1.0 release +> git bisect good 9e06029aea3b2eca1d5261352e695edc1e7d7b8b +> # bad: [98b2e3c9ab3abfe476a2b02f8f51813edb90e72d] Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging +> git bisect bad 98b2e3c9ab3abfe476a2b02f8f51813edb90e72d +> # good: [56e6250ede81b4e4b4ddb623874d6c3cdad4a96d] target/arm: Convert T16, nop hints +> git bisect good 56e6250ede81b4e4b4ddb623874d6c3cdad4a96d +> # good: [5d69cbdfdd5cd6dadc9f0c986899844a0e4de703] tests/tcg: target/s390x: Test MVC +> git bisect good 5d69cbdfdd5cd6dadc9f0c986899844a0e4de703 +> # good: [88112488cf228df8b7588c8aa38e16ecd0dff48e] qapi: Make check_type()'s array case a bit more obvious +> git bisect good 88112488cf228df8b7588c8aa38e16ecd0dff48e +> # good: [972bd57689f1e11311d86b290134ea2ed9c7c11e] ppc/kvm: Skip writing DPDES back when in run time state +> git bisect good 972bd57689f1e11311d86b290134ea2ed9c7c11e +> # bad: [1aba8716c8335e88b8c358002a6e1ac89f7dd258] ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine +> git bisect bad 1aba8716c8335e88b8c358002a6e1ac89f7dd258 +> # bad: [00ed3da9b5c2e66e796a172df3e19545462b9c90] xics: Minor fixes for XICSFabric interface +> git bisect bad 00ed3da9b5c2e66e796a172df3e19545462b9c90 +> # good: [33432d7737b53c92791f90ece5dbe3b7bb1c79f5] target/ppc: introduce set_dfp{64,128}() helper functions +> git bisect good 33432d7737b53c92791f90ece5dbe3b7bb1c79f5 +> # good: [f6d4c423a222f02bfa84a49c3d306d7341ec9bab] target/ppc: remove unnecessary if() around calls to set_dfp{64,128}() in DFP macros +> git bisect good f6d4c423a222f02bfa84a49c3d306d7341ec9bab +> # bad: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] spapr: Render full FDT on ibm,client-architecture-support +> git bisect bad e68cd0cb5cf49d334abe17231a1d2c28b846afa2 +> # good: [c4ec08ab70bab90685d1443d6da47293e3aa312a] spapr-pci: Stop providing assigned-addresses +> git bisect good c4ec08ab70bab90685d1443d6da47293e3aa312a +> # first bad commit: [e68cd0cb5cf49d334abe17231a1d2c28b846afa2] +> spapr: Render full FDT on ibm,client-architecture-support + +Ah, dammit, I thought we'd fixed the problems with that patch :(. + +> +> attached vmxml. +> +> qemu commandline: +> /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-19-vm1/master-key.aes -machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off -m 81920 -overcommit mem-lock=off -smp 512,sockets=1,cores=128,threads=4 -uuid fd4a5d54-0216-490e-82d2-1d4e89683b3d -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=24,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/sath/tests/data/avocado-vt/images/jeos-27-ppc64le_vm1.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=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:df:24,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -M pseries,ic-mode=xics -msg timestamp=on +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: kvm powerpcm qemu + +-- +David Gibson | I'll have my music baroque, and my code +david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ + | _way_ _around_! +http://www.ozlabs.org/~dgibson + + +Ok, I just tried booting a guest with virtio-scsi and ic-mode=xics, and I wasn't able to reproduce this problem. + +Can you try simplifying your command line to see what options are needed to trigger this? + +Oh... are you using the SLOF (guest firmware) image included in the qemu tree, or is it coming from a separate package? + + +If it's from a separate package, that could be the problem - it needs to be updated before that qemu patch is safe. + + +Did try with the slof bin(-bios /usr/local/share/qemu/slof.bin) complied with qemu tree also, same issue persists, + + +/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-2-vm1/master-key.aes \ +-machine pseries-4.2,accel=kvm,usb=off,dump-guest-core=off \ +-bios /usr/local/share/qemu/slof.bin \ +-m 81920 \ +-overcommit mem-lock=off \ +-smp 512,sockets=1,cores=128,threads=4 \ +-uuid fd4a5d54-0216-490e-82d2-1d4e89683b3d \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=24,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device qemu-xhci,id=usb,bus=pci.0,addr=0x3 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 \ +-drive file=/home/sath/tests/data/avocado-vt/images/jeos-27-ppc64le_vm1.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=26,id=hostnet0,vhost=on,vhostfd=27 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:df:24,bus=pci.0,addr=0x1 \ +-chardev pty,id=charserial0 \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ +-M pseries,ic-mode=dual \ +-msg timestamp=on + + +Did try with xics aswell, same issue. + +Host HW: + +#lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 128 +On-line CPU(s) list: 0-127 +Thread(s) per core: 4 +Core(s) per socket: 16 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9, altivec supported +CPU max MHz: 3800.0000 +CPU min MHz: 2300.0000 +L1d cache: 32K +L1i cache: 32K +L2 cache: 512K +L3 cache: 10240K +NUMA node0 CPU(s): 0-63 +NUMA node8 CPU(s): 64-127 + + +FW: skiboot-v6.3.2 + +Regards, +-Satheesh + +Please provide the entire guest booting output, from slof till it is stuck. +Also please try with -smp 1. Thanks. + +Domain vm1 started +Connected to domain vm1 +Escape character is ^] +Populating /vdevice methods +Populating /vdevice/vty@30000000 +Populating /vdevice/nvram@71000000 +Populating /pci@800000020000000 + 00 0800 (D) : 1af4 1000 virtio [ net ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" + 00 1800 (D) : 1b36 000d serial bus [ usb-xhci ] + 00 2000 (D) : 1af4 1002 unknown-legacy-device* +No NVRAM common partition, re-initializing... +Scanning USB + XHCI: Initializing +Using default console: /vdevice/vty@30000000 + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /pci@800000020000000/scsi@2/disk@100000000000000 ... Successfully loaded + + +OF stdout device is: /vdevice/vty@30000000 +Preparing to boot Linux version 4.13.9-300.fc27.ppc64le (<email address hidden>) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Mon Oct 23 13:28:27 UTC 2017 +Detected machine type: 0000000000000101 +command line: BOOT_IMAGE=/boot/vmlinuz-4.13.9-300.fc27.ppc64le root=UUID=500d2159-c568-459e-8864-1c21b3519a80 ro console=tty0 console=ttyS0,115200 console=hvc0 +Max number of cores passed to firmware: 1024 (NR_CPUS = 1024) +Calling ibm,client-architecture-support...Node not supported +Node not supported + not implemented +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 00000000046a0000 + alloc_top : 0000000010000000 + alloc_top_hi : 0000001400000000 + rmo_top : 0000000010000000 + ram_top : 0000001400000000 +instantiating rtas at 0x000000000daf0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x00000000046b0000 -> 0x00000000046b0b3f +Device tree struct 0x00000000046c0000 -> 0x00000000046d0000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000002000000 ... +[ 0.000000] Page sizes from device-tree: +[ 0.000000] Page size shift = 12 AP=0x0 +[ 0.000000] Page size shift = 16 AP=0x5 +[ 0.000000] Page size shift = 21 AP=0x1 +[ 0.000000] Page size shift = 30 AP=0x2 +[ 0.000000] Using radix MMU under hypervisor +[ 0.000000] Mapped range 0x0 - 0x1400000000 with 0x40000000 +[ 0.000000] Process table c0000013ff000000 and radix root for kernel: c0000000014c0000 +[ 0.000000] Linux version 4.13.9-300.fc27.ppc64le (<email address hidden>) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Mon Oct 23 13:28:27 UTC 2017 +[ 0.000000] Found initrd at 0xc000000003900000:0xc0000000046967f5 +[ 0.000000] Using pSeries machine description +[ 0.000000] bootconsole [udbg0] enabled +[ 0.000000] Partition configured for 2 cpus. +[ 0.000000] CPU maps initialized for 1 thread per core + -> smp_release_cpus() +spinning_secondaries = 1 + <- smp_release_cpus() +[ 0.000000] ----------------------------------------------------- +[ 0.000000] ppc64_pft_size = 0x0 +[ 0.000000] phys_mem_size = 0x1400000000 +[ 0.000000] dcache_bsize = 0x80 +[ 0.000000] icache_bsize = 0x80 +[ 0.000000] cpu_features = 0x075c7a7c18500249 +[ 0.000000] possible = 0x5fffffff18500649 +[ 0.000000] always = 0x0000000018100040 +[ 0.000000] cpu_user_features = 0xdc0065c2 0xaee00000 +[ 0.000000] mmu_features = 0x3c006041 +[ 0.000000] firmware_features = 0x00000001455a445f +[ 0.000000] ----------------------------------------------------- +[ 0.000000] numa: NODE_DATA [mem 0x13fffe7e80-0x13ffff1b7f] +[ 0.000000] PCI host bridge /pci@800000020000000 ranges: +[ 0.000000] IO 0x0000200000000000..0x000020000000ffff -> 0x0000000000000000 +[ 0.000000] MEM 0x0000200080000000..0x00002000ffffffff -> 0x0000000080000000 +[ 0.000000] MEM 0x0000210000000000..0x000021ffffffffff -> 0x0000210000000000 +[ 0.000000] OF: PCI: PROBE_ONLY disabled +[ 0.000000] PPC64 nvram contains 65536 bytes +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000000000-0x00000013ffffffff] +[ 0.000000] DMA32 empty +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000000000-0x00000013ffffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000013ffffffff] +[ 0.000000] percpu: Embedded 3 pages/cpu @c0000013fef80000 s151064 r0 d45544 u196608 +[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1309440 +[ 0.000000] Policy zone: DMA +[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.9-300.fc27.ppc64le root=UUID=500d2159-c568-459e-8864-1c21b3519a80 ro console=tty0 console=ttyS0,115200 console=hvc0 +[ 0.000000] PID hash table entries: 4096 (order: -1, 32768 bytes) +[ 0.000000] Memory: 83754240K/83886080K available (11968K kernel code, 1792K rwdata, 3136K rodata, 4288K init, 2405K bss, 131840K reserved, 0K cma-reserved) +[ 0.000000] random: get_random_u64 called from cache_random_seq_create+0xa0/0x180 with crng_init=0 +[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 29419 entries in 11 pages +[ 0.000000] Hierarchical RCU implementation. +[ 0.000000] RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=2. +[ 0.000000] Tasks RCU enabled. +[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 +[ 0.000000] time_init: 56 bit decrementer (max: 7fffffffffffff) +[ 0.000483] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns +[ 0.001327] clocksource: timebase mult[1f40000] shift[24] registered +[ 0.001868] Console: colour dummy device 80x25 +[ 0.002310] console [tty0] enabled +[ 0.002588] console [hvc0] enabled +[ 0.002588] console [hvc0] enabled +[ 0.002890] bootconsole [udbg0] disabled +[ 0.002890] bootconsole [udbg0] disabled +[ 0.003238] pid_max: default: 32768 minimum: 301 +[ 0.003336] Security Framework initialized +[ 0.003361] Yama: becoming mindful. +[ 0.003387] SELinux: Initializing. +[ 0.008989] Dentry cache hash table entries: 8388608 (order: 10, 67108864 bytes) +[ 0.011926] Inode-cache hash table entries: 4194304 (order: 9, 33554432 bytes) +[ 0.012030] Mount-cache hash table entries: 131072 (order: 4, 1048576 bytes) +[ 0.012237] Mountpoint-cache hash table entries: 131072 (order: 4, 1048576 bytes) +[ 0.012576] EEH: pSeries platform initialized +[ 0.012611] POWER9 performance monitor hardware support registered +[ 0.012664] Hierarchical SRCU implementation. +[ 0.013001] smp: Bringing up secondary CPUs ... +[ 0.015623] smp: Brought up 1 node, 2 CPUs +[ 0.015662] numa: Node 0 CPUs: 0-1 +[ 0.019886] devtmpfs: initialized +[ 0.024963] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 0.025027] futex hash table entries: 512 (order: 0, 65536 bytes) +[ 0.025177] NET: Registered protocol family 16 +[ 0.027932] EEH: No capable adapters found +[ 0.030363] cpuidle: using governor menu +[ 0.031979] pstore: using zlib compression +[ 0.032005] pstore: Registered nvram as persistent store backend +Linux ppc64le +#1 SMP Mon Oct 2[ 0.035136] PCI: Probing PCI hardware +[ 0.035185] PCI host bridge to bus 0000:00 +[ 0.035210] pci_bus 0000:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff]) +[ 0.035260] pci_bus 0000:00: root bus resource [mem 0x200080000000-0x2000ffffffff] (bus address [0x80000000-0xffffffff]) +[ 0.035318] pci_bus 0000:00: root bus resource [mem 0x210000000000-0x21ffffffffff] +[ 0.035360] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.037044] IOMMU table initialized, virtual merging enabled +[ 0.037088] iommu: Adding device 0000:00:01.0 to group 0, default domain type -1 +[ 0.037145] pci 0000:00:01.0: of_irq_parse_pci: failed with rc=134 +[ 0.037190] iommu: Adding device 0000:00:02.0 to group 0, default domain type -1 +[ 0.037242] pci 0000:00:02.0: of_irq_parse_pci: failed with rc=134 +[ 0.037286] iommu: Adding device 0000:00:03.0 to group 0, default domain type -1 +[ 0.037337] pci 0000:00:03.0: of_irq_parse_pci: failed with rc=134 +[ 0.037380] iommu: Adding device 0000:00:04.0 to group 0, default domain type -1 +[ 0.037442] pci 0000:00:04.0: of_irq_parse_pci: failed with rc=134 +[ 0.043219] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.043275] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.051951] vgaarb: loaded +[ 0.052021] SCSI subsystem initialized +[ 0.054039] usbcore: registered new interface driver usbfs +[ 0.054076] usbcore: registered new interface driver hub +[ 0.054113] usbcore: registered new device driver usb +[ 0.055226] EDAC MC: Ver: 3.0.0 +[ 0.060393] NetLabel: Initializing +[ 0.060419] NetLabel: domain hash size = 128 +[ 0.060447] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.060492] NetLabel: unlabeled traffic allowed by default +[ 0.062836] clocksource: Switched to clocksource timebase +[ 0.073228] VFS: Disk quotas dquot_6.6.0 +[ 0.073275] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +[ 0.318455] NET: Registered protocol family 2 +[ 0.318612] TCP established hash table entries: 524288 (order: 6, 4194304 bytes) +[ 0.319695] TCP bind hash table entries: 65536 (order: 4, 1048576 bytes) +[ 0.319940] TCP: Hash tables configured (established 524288 bind 65536) +[ 0.320000] UDP hash table entries: 65536 (order: 5, 2097152 bytes) +[ 0.320342] UDP-Lite hash table entries: 65536 (order: 5, 2097152 bytes) +[ 0.320713] NET: Registered protocol family 1 +[ 0.320782] pci 0000:00:03.0: enabling device (0000 -> 0002) +[ 0.320897] Unpacking initramfs... +[ 0.536932] Freeing initrd memory: 13888K +[ 0.540445] rtas_flash: no firmware flash support +[ 0.540685] audit: initializing netlink subsys (disabled) +[ 0.544654] Initialise system trusted keyrings +[ 0.544693] Key type blacklist registered +[ 0.545355] audit: type=2000 audit(1571635628.541:1): state=initialized audit_enabled=0 res=1 +[ 0.547068] workingset: timestamp_bits=38 max_order=21 bucket_order=0 +[ 0.548074] zbud: loaded +[ 0.693638] random: fast init done +[ 0.756362] NET: Registered protocol family 38 +[ 0.756416] Key type asymmetric registered +[ 0.756450] Asymmetric key parser 'x509' registered +[ 0.756535] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250) +[ 0.757780] io scheduler noop registered +[ 0.757818] io scheduler deadline registered +[ 0.757900] io scheduler cfq registered (default) +[ 0.757944] io scheduler mq-deadline registered +[ 0.758947] atomic64_test: passed +[ 0.773254] libphy: Fixed MDIO Bus: probed +[ 0.775507] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.775573] ehci-pci: EHCI PCI platform driver +[ 0.775625] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.775685] ohci-pci: OHCI PCI platform driver +[ 0.775734] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.775841] xhci_hcd 0000:00:03.0: enabling device (0000 -> 0002) +[ 0.775953] xhci_hcd 0000:00:03.0: xHCI Host Controller +[ 0.777192] xhci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 1 +[ 0.777541] xhci_hcd 0000:00:03.0: ibm,query-pe-dma-windows(2026) 1800 2000 0 returned -3 +[ 0.778091] xhci_hcd 0000:00:03.0: hcc params 0x00087001 hci version 0x100 quirks 0x00000010 +[ 0.778169] xhci_hcd 0000:00:03.0: No msi-x/msi found and no IRQ in BIOS +[ 0.778223] xhci_hcd 0000:00:03.0: startup error -22 +[ 0.778268] xhci_hcd 0000:00:03.0: USB bus 1 deregistered +[ 0.780041] xhci_hcd 0000:00:03.0: init 0000:00:03.0 fail, -22 +[ 0.780101] xhci_hcd: probe of 0000:00:03.0 failed with error -22 +[ 0.780174] usbcore: registered new interface driver usbserial +[ 0.780233] usbcore: registered new interface driver usbserial_generic +[ 0.780291] usbserial: USB Serial support registered for generic +[ 0.782554] mousedev: PS/2 mouse device common for all mice +[ 0.782886] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 +[ 0.783012] device-mapper: uevent: version 1.0.3 +[ 0.784846] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: <email address hidden> +[ 0.786176] hidraw: raw HID events driver (C) Jiri Kosina +[ 0.786257] usbcore: registered new interface driver usbhid +[ 0.786300] usbhid: USB HID core driver +[ 0.786388] drop_monitor: Initializing network drop monitor service +[ 0.786511] ip_tables: (C) 2000-2006 Netfilter Core Team +[ 0.786564] Initializing XFRM netlink socket +[ 0.786734] NET: Registered protocol family 10 +[ 0.794930] Segment Routing with IPv6 +[ 0.794983] mip6: Mobile IPv6 +[ 0.795015] NET: Registered protocol family 17 +[ 0.800017] registered taskstats version 1 +[ 0.800060] Loading compiled-in X.509 certificates +[ 0.850282] Loaded X.509 cert 'Fedora kernel signing key: a878db2990f3e3239cc963ffd6fea115d9415954' +[ 0.850347] zswap: loaded using pool lzo/zbud +[ 0.857402] Key type big_key registered +[ 0.864367] Key type encrypted registered +[ 0.865572] rtc-generic rtc-generic: setting system clock to 2019-10-21 05:27:08 UTC (1571635628) +[ 0.866653] Freeing unused kernel memory: 4288K +[ 0.866684] This architecture does not have kernel memory protection. +[ 0.872683] systemd[1]: systemd 234 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid) +[ 0.872817] systemd[1]: Detected virtualization kvm. +[ 0.872855] systemd[1]: Detected architecture ppc64-le. +[ 0.872885] systemd[1]: Running in initial RAM disk. + +Welcome to Fedora 27 (Twenty Seven) dracut-046-5.fc27 (Initramfs)! + +[ 0.873073] systemd[1]: Set hostname to <atest-guest>. +[ 0.952006] systemd[1]: Listening on Journal Audit Socket. +[ OK ] Listening on Journal Audit Socket. +[ 0.952292] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. +[ OK ] Started Dispatch Password Requests to Console Directory Watch. +[ 0.952488] systemd[1]: Reached target Paths. +[ OK ] Reached target Paths. +[ 0.952639] systemd[1]: Reached target Local File Systems. +[ OK ] Reached target Local File Systems. +[ 0.952816] systemd[1]: Reached target Timers. +[ OK ] Reached target Timers. +[ OK ] Listening on Journal Socket (/dev/log). +[ OK ] Listening on Journal Socket. +[ OK ] Reached target Swap. +[ OK ] Listening on udev Control Socket. +[ OK ] Listening on udev Kernel Socket. +[ OK ] Reached target Sockets. +[ OK ] Created slice System Slice. + Starting Create Volatile Files and Directories... + Starting Create list of required st…ce nodes for the current kernel... +[ OK ] Reached target Slices. + Starting Journal Service... + Starting Apply Kernel Variables... +[ OK ] Started Create Volatile Files and Directories. +[ OK ] Started Apply Kernel Variables. +[ OK ] Started Create list of required sta…vice nodes for the current kernel. + Starting Create Static Device Nodes in /dev... +[ OK ] Started Create Static Device Nodes in /dev. +[ 0.967752] audit: type=1130 audit(1571635628.603:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-tmpfiles-setup-dev comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' + Starting udev Kernel Device Manager... +[ OK ] Started Journal Service. +[ 0.973468] audit: type=1130 audit(1571635628.608:3): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ OK ] Started udev Kernel Device Manager. + Starting udev Coldplug all Devices... +[ 0.975851] audit: type=1130 audit(1571635628.610:4): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' + Mounting Kernel Configuration File System... +[ OK ] Mounted Kernel Configuration File System. +[ 1.039675] virtio-pci 0000:00:01.0: enabling device (0000 -> 0003) +[ 1.039749] virtio-pci 0000:00:01.0: virtio_pci: leaving for legacy driver +[ 1.041139] synth uevent: /devices/vio: failed to send uevent +[ 1.041140] vio vio: uevent: failed to send synthetic uevent +[ OK ] Started udev Coldplug all Devices. +[ 1.042946] audit: type=1130 [audit(1571635628 OK id=1 umid=0 auid=429496] Reached target R7295 ses=4294967e295 subj=kernel mote File Systemmsg='unit=systemsd-udev-trigger c (Pre).omm="systemd" ex +e="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 1.043884] virtio-pci 0000:00:02.0: enabling device (0000 -> 0003) +[ 1.043908] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver +[ 1.043979] virtio-pci 0000:00:04.0: enabling device (0000 -> 0003) +[ 1.044003] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver +[ OK ] Reached target Remote File Systems. +[ OK ] Reached target System Initialization. +[ OK ] Reached target Basic System. +[ 1.102715] virtio_scsi: probe of virtio1 failed with error -22 +[** ] A start job is running for dev-disk…19a80.device (1min 50s / no limit) + + +Same observation with smp 1 even. + +https://patchwork.ozlabs.org/patch/1180363/ should fix it, a SLOF update for QEMU is also posted +https://github.com/aik/qemu/tree/qemu-slof-20191022-branch + +The SLOF fix has been merged 1.5 years ago, so I assume this can be marked as fixed now. + diff --git a/results/classifier/105/KVM/1848244 b/results/classifier/105/KVM/1848244 new file mode 100644 index 00000000..1f05b202 --- /dev/null +++ b/results/classifier/105/KVM/1848244 @@ -0,0 +1,29 @@ +KVM: 0.896 +graphic: 0.637 +device: 0.615 +instruction: 0.566 +semantic: 0.435 +mistranslation: 0.383 +boot: 0.296 +other: 0.225 +socket: 0.181 +network: 0.176 +vnc: 0.155 +assembly: 0.073 + +QEMU KVM IGD SandyBridge Passthrough crash + +I try to passthrough my Intel GPU with this command: + +qemu-system-x86_64 -nodefaults -parallel none -k de -rtc base=localtime -serial unix:/run/qemu/win7-serial.sock,server,nowait -monitor unix:/run/qemu/win7-monitor.sock,server,nowait -netdev user,id=net0 -device virtio-net-pci,netdev=net0,mac=52:54:00:00:00:07 -device vfio-pci,host=0000:00:02.0,addr=0x2 -device vfio-pci,host=0000:00:1b.0 -device virtio-keyboard-pci -device virtio-mouse-pci -object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:00:1a.0-usb-0:1.2.2:1.2-event-kbd,grab_all=on,repeat=on -object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:00:1a.0-usb-0:1.2.2:1.2-event-mouse -enable-kvm -cpu host -smp 4,sockets=1,cores=4,threads=1 -vga none -display none -m 2g -device virtio-blk-pci,drive=boot,bootindex=1 -drive file=/opt/vm/qcow2/win7.qcow2,format=qcow2,if=none,id=boot + +This ONLY works if i remove "-enable-kvm" else the windows (7 and 10) boot crashes in bluescreen "stop 0x0000003b" (probably while loading the intel gpu driver (intel graphics 3000). + +The system is an older ThinkPad T420 with Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz. + +CMDLINE: BOOT_IMAGE=/vmlinuz-linux root=LABEL=root rw ipv6.disable=0 net.ifnames=0 intel_iommu=on iommu=pt video=LVDS-1:d + +Solved: I added kvm.ignore_msrs=1 to kernel parameter! + +I'm closing this now since there seems to be a workaround available and nobody updated this bug in the past 1.5 years anymore + diff --git a/results/classifier/105/KVM/1851972 b/results/classifier/105/KVM/1851972 new file mode 100644 index 00000000..0d0faa70 --- /dev/null +++ b/results/classifier/105/KVM/1851972 @@ -0,0 +1,135 @@ +KVM: 0.700 +other: 0.554 +vnc: 0.552 +mistranslation: 0.494 +instruction: 0.481 +graphic: 0.451 +network: 0.437 +boot: 0.423 +device: 0.413 +socket: 0.389 +assembly: 0.335 +semantic: 0.311 + +pc-q35-4.1 and AMD Navi 5700/XT incompatible + +Hello, + +I am not sure if this qualifies as a "bug"; it is be more of an unknown issue with default settings. However, since the default value of q35 default_kernel_irqchip_split was changed seemingly due to similar user feedback, I thought this was important to share.. + +AMD Navi 5700/XT vfio-pci passthrough seems incompatible with one/multiple settings in pc-q35-3.1 and higher. The workaround for me is that pc-q35-3.0 still works fine passing through the GPU and official drivers can load/install fine. + +The default/generic GPU drivers in a Fedora 30 or Windows 1903 guest do work; the monitor displays the desktop in a 800x600 resolution and things are rendered fine.. so the basic functionality of the card seems fine with pc-q35-4.1. + +But attempting to use the official open source AMD driver with the card resulted in a hung kernel for the Fedora 30 guest.. and a BSOD on the Windows 1903 guest immediately during driver install. + +I do not see any errors in Qemu command output.. did not investigate other logs or KVM etc, because I am not sure what to look for or how to go about it. Also not sure which combination of the latest q35 default settings are valid combinations to try either, because it seems that multiple things have changed related to pcie-root-port defaults and other machine options. I am happy to run tests and provide feedback if that helps identify the issue. + +I am using "Linux arch 5.4.0-rc6-mainline" kernel on ArchLinux host with AMD Navi reset pci quirk patch applied. + +My working Qemu command line is this: + +QEMU_AUDIO_DRV=pa \ +QEMU_PA_SERVER=/run/user/1000/pulse/native \ +/usr/bin/qemu-system-x86_64 \ +-name windows \ +-m 16g \ +-accel kvm \ +-machine pc-q35-3.0,accel=kvm,pflash0=ovmf0,pflash1=ovmf1 \ +-blockdev node-name=ovmf0,driver=file,filename=/virt/qemu/roms/OVMF_CODE.fd,read-only=on \ +-blockdev node-name=ovmf1,driver=file,filename=/virt/qemu/machines/windows/OVMF_VARS.fd \ +-boot menu=on \ +-global kvm-pit.lost_tick_policy=discard \ +-no-hpet \ +-rtc base=utc,clock=host,driftfix=slew \ +-cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \ +-smp sockets=1,cores=4,threads=1 \ +-nodefaults \ +-netdev bridge,br=br0,id=net0 \ +-device virtio-net-pci,netdev=net0,addr=19.0,mac=52:54:00:12:34:77 \ +-device virtio-scsi-pci \ +-blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \ +-device scsi-hd,drive=disk0,rotation_rate=1 \ +-blockdev raw,node-name=disk1,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/data.raw \ +-device scsi-hd,drive=disk1,rotation_rate=1 \ +-drive index=0,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/Win10_1903_V2_English_x64.iso \ +-drive index=1,if=ide,media=cdrom,readonly,file=/virt/qemu/isos/virtio-win-0.1.173.iso \ +-device ich9-intel-hda,addr=1b.0 \ +-device hda-output \ +-monitor stdio \ +-display none \ +-vga none \ +-device pcie-root-port,id=pcierp0,chassis=1,slot=1,addr=1c.0,disable-acs=on,multifunction=on \ +-device pcie-root-port,id=pcierp1,chassis=2,slot=2,addr=1c.1,disable-acs=on \ +-device x3130-upstream,bus=pcierp0,id=pcieu0 \ +-device xio3130-downstream,bus=pcieu0,id=pcied0,chassis=11,slot=11 \ +-device vfio-pci,host=03:00.0,bus=pcied0,addr=00.0,multifunction=on \ +-device vfio-pci,host=03:00.1,bus=pcied0,addr=00.1 \ +-device qemu-xhci,addr=1d.0 \ +-device usb-host,vendorid=0x258a,productid=0x0001 \ +-device usb-host,vendorid=0x1bcf,productid=0x0005 ; + +Thank you! + +Paolo Bonzini commented on IRC: AMD avic requires kernel_irqchip=split. + +Can you try using it? (released QEMU uses -machine ...,kernel_irqchip=split, git QEMU expects -accel kernel_irqchip=split). + +Hi Philippe, thanks for replying. + +The 'kernel_irqchip' parameter is a bit confusing to me. It looks like the documentation was updated from it defaulted to 'off' as a -machine parameter, to now it will default to 'on' as an -accel parameter. + +This bug described how the value for 'default_kernel_irqchip_split' parameter had been changed to 'true' in Q35 version 4.0, but then set back to 'false' after discovering that it caused issues for Nvidia gpu passthrough and other things: https://bugs.launchpad.net/qemu/+bug/1826422 + +However, my problems with the AMD gpu passthrough are present when switching between Q35 3.0 (which does work) and 3.1 (which does not work), both of which would still have 'default_kernel_irqchip_split' set to false.. so it does not seem to me to be related to 'kernel_irqchip'. + +Q35 version 3.1 did introduce many other changes: + +static void pc_q35_3_1_machine_options(MachineClass *m) +{ +.. + pcmc->do_not_add_smb_acpi = true; + m->smbus_no_migration_support = true; + m->alias = NULL; + pcmc->pvh_enabled = false; +.. + +GlobalProperty hw_compat_3_1[] = { + { "pcie-root-port", "x-speed", "2_5" }, + { "pcie-root-port", "x-width", "1" }, +.. + +I thought maybe those could cause the AMD Navi gpu problems, but I am not that knowledgeable about these settings. + +Also I do not have the AMD Navi gpu conveniently available anymore to test. + +Commit 11bc4a13 (Nov 13, 2019, merged after v4.2.0-rc5) moved the kernel-irqchip parameter to -accel, but I think the default was inadvertently changed to off. The documentation was changed to say the default is on, but the code change seems to have done the opposite. + +I found this when I tested my Windows Server 2016 VMs with the last qemu from git. Windows boots and runs very slowly unless I add either <ioapic driver='kvm'/> (kernel_irqchip=on) or <timer name="hypervclock" present="yes"/> to the libvirt config. Using the qemu installed with Ubuntu 19.10 (version 4.0.0), I can reproduce the slowness by explicitly adding kernel_irqchip=off. + +Details: +- Host CPU: Ryzen 3950X (16 core, 32 thread) +- Host RAM: 64 GiB +- Host OS: Ubuntu 19.10 64-bit, kernel version 5.5.0-rc4 (commit 738d2902773e + ACS override patch) +- Guest CPU: host-passthrough, 16 vcpus (8 cores, 2 threads, topoext). +- Guest RAM: 12 GiB +- Guest machine type: pc-i440fx-4.0 (BIOS boot) +- Guest OS: Windows Server 2016, build 1607 + +Commit d1972be13f ("accel/kvm: Make "kernel_irqchip" default on") fixes the default mixup I described above. This isn't related to Marshall's issue as it involves qemu 3.0 vs 3.1, but at least it cleans up some confusion. + +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/105/KVM/1852781 b/results/classifier/105/KVM/1852781 new file mode 100644 index 00000000..1637eb48 --- /dev/null +++ b/results/classifier/105/KVM/1852781 @@ -0,0 +1,84 @@ +KVM: 0.960 +mistranslation: 0.959 +boot: 0.947 +vnc: 0.938 +instruction: 0.936 +graphic: 0.932 +device: 0.930 +socket: 0.929 +other: 0.929 +assembly: 0.917 +semantic: 0.915 +network: 0.912 + +qemu s390x on focal - applications breaking + +Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering random breakage, for example: + +sudo apt-get update && sudo apt-get dist-upgrade + +... +... + +Unpacking debianutils (4.9) over (4.8.6.3) ... +Setting up debianutils (4.9) ... +Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 43. +(Reading database ... 83640 files and directories currently installed.) +Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ... +Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ... +Setting up bash (5.0-5ubuntu1) ... +[12124.788618] User process fault: interruption code 0007 ilc:3 in bash[2aa3d780000+149000] +dpkg: error processing package bash (--configure): + installed bash package post-installation script subprocess was killed by signal (Floating point exception), core du +mped +Errors were encountered while processing: + bash +E: Sub-process /usr/bin/dpkg returned an error code (1) + +And now bash is completely broken: + +cking@eoan-s390x:~$ bash +[12676.204389] User process fault: interruption code 0007 ilc:3 in bash[2aa14780000+149000] + +Floating point exception (core dumped) + +The upgrade works OK on a s390x, so I'm assuming it's something to do with the qemu emulation. + +I've also seen in the dmesg log: + +[ 287.624414] User process fault: interruption code 0007 ilc:3 in libstdc++.so.6.0.28[3ffb3e00000+21d000] +[ 288.991706] User process fault: interruption code 0007 ilc:3 in libstdc++.so.6.0.28[3ff90080000+21d000] + +ps is showing QEMU is running as follows: + +/usr/bin/qemu-system-s390x -name guest=ubuntu20.04-focal-s390x,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-ubuntu20.04-focal-s3/master-key.aes -machine s390-ccw-virtio-eoan,accel=tcg,usb=off,dump-guest-core=off -m 2048 -overcommit mem-lock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 6501dfbf-16d7-4412-a9d5-1ee808b42804 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=24,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0002 -device virtio-serial-ccw,id=virtio-serial0,devno=fe.0.0003 -drive file=/pool-ssd/virt/ubuntu19.10-eaon-s390x-clone,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-0,readonly=on -device scsi-cd,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 -netdev tap,fd=27,id=hostnet0 -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:a3:21:68,devno=fe.0.0001 -chardev socket,id=charchannel0,fd=28,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev pty,id=charconsole0 -device sclpconsole,chardev=charconsole0,id=console0 -device virtio-balloon-ccw,id=balloon0,devno=fe.0.0004 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-ccw,rng=objrng0,id=rng0,devno=fe.0.0005 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +Hi Colin, +I didn't read much if the details but I think it is clear. + +Per request of IBM focal got -march=z13 but tcg has no emulation for some +of the instructions of this cpu. + +That is the breakage that you are seeing and afaik there is nothing we can +do than waiting for qemu to grow that support. + + +Can you please test again with the latest QEMU 4.2 RC? There have been quite a lot of fixes in this area in the past months, so maybe this issue has already been resolved in 4.2. + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for Ubuntu on IBM z Systems because there has been no activity for 60 days.] + +FYI - Focal now contains 4.2 which might (or not) have the bits you need. +You most likely get further, but I can't give guarantees if enough of march=z13 is supported to work for a full Focal (not sure on vector instructions for example) including all of userspace. + +Marking it incomplete - if someone wants to try please go for it and let us know. +Otherwise let it expire again ... + +Seems like you have to set all to "incomplete" to restart the expire counter again... + +[Expired for Ubuntu on IBM z Systems because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1853123 b/results/classifier/105/KVM/1853123 new file mode 100644 index 00000000..5f1135af --- /dev/null +++ b/results/classifier/105/KVM/1853123 @@ -0,0 +1,62 @@ +KVM: 0.893 +device: 0.877 +network: 0.813 +graphic: 0.785 +instruction: 0.665 +semantic: 0.654 +other: 0.570 +mistranslation: 0.555 +boot: 0.388 +socket: 0.364 +vnc: 0.364 +assembly: 0.132 + +Memory synchronization error between kvm and target, e1000(dpdk) + +Hi folks. + +I use linux with dpdk drivers on the target system, and e1000 emulation device with tap interface for host. I use kvm for accelerate. +Version qemu 4.0.94 and master (Nov 12 10:14:33 2019) +Version dpdk stable-17.11.4 +Version linux host 4.15.0-66-generic (ubuntu 18.04) + +I type command "ping <target ip> -f" and wait about 1-2 minutes. Network subsystem freezes. + +For receive the eth pack from host system (tap interface) to host system the e1000 using ring buffer. + +The e1000 write body of eth pack, set E1000_RXD_STAT_DD flag and move RDH (Ring Device Head). +(file hw/net/e1000.c function e1000_receive_iov() ) + +The dpdk driver is reading from E1000_RXD_STAT_DD flags (ignoring RDH), if flag is set: read buffer, unset flag E1000_RXD_STAT_DD and move RDT (Ring Device Tail). +(source drivers/net/e1000/em_rxtx.c function eth_em_recv_scattered_pkts() ) + +I see what the driver unet E1000_RXD_STAT_DD (rxdp->status = 0; ), but sometimes rxdp->status remains equal to 7. On the next cycle, this this buffer is read, RDT moved to far. RDH becomes equal RDT and network is freezes. + +If I insert some delay after unset E1000_RXD_STAT_DD, and repeatedly unset E1000_RXD_STAT_DD (if rxdp->status == 7 ), then all work fine. +If check E1000_RXD_STAT_DD without delay, status rxdp->status always valid. + +This only appears on kvm. If I use tcg all works fine. + +I trying set watchpoint for memory on the qemu (for tcg), and see, that for one package cycle of set/unse STAT_DD repeated once. + +I trying set watchpoint for memory on the qemu (for kvm), and see, that rxdp->status changed to 0(unset) only once, but is changes immediately before set flag. + + +Please help me with advice on how to catch and fix this error. +Theoretically, it would help me to trace the memory access when writing to E1000_RXD_STAT_DD, RHD and RDT, both from the target and the host system. But I have no idea how this can be done. + +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/105/KVM/1859310 b/results/classifier/105/KVM/1859310 new file mode 100644 index 00000000..659d4702 --- /dev/null +++ b/results/classifier/105/KVM/1859310 @@ -0,0 +1,36 @@ +KVM: 0.975 +device: 0.916 +instruction: 0.844 +semantic: 0.804 +mistranslation: 0.791 +socket: 0.751 +graphic: 0.745 +other: 0.613 +network: 0.593 +vnc: 0.542 +boot: 0.425 +assembly: 0.157 + +libvirt probing fails due to assertion failure with KVM and 'none' machine type + +Using libvirt on Ubuntu 19.10, I get the following error when I try to set <emulator> to the latest qemu from git (commit dc65a5bdc9): + + error: internal error: Failed to start QEMU binary /usr/local/bin/qemu-system-x86_64 for probing: /home/joey/git/qemu/target/i386/kvm.c:2176:kvm_arch_init: Object 0x564bfd5c3200 is not an instance of type x86-machine + +Qemu command line to reproduce: + + sudo x86_64-softmmu/qemu-system-x86_64 -machine 'none,accel=kvm' + +Commit ed9e923c3c (Dec 12, 2019) introduced the issue by removing an object_dynamic_cast call. In this scenario, kvm_arch_init is passed an instance of "none-machine" instead of "x86-machine". + +The following one-line change to target/i386/kvm.c reintroduces the cast: + + if (kvm_check_extension(s, KVM_CAP_X86_SMM) && ++ object_dynamic_cast(OBJECT(ms), TYPE_X86_MACHINE) && + x86_machine_is_smm_enabled(X86_MACHINE(ms))) { + smram_machine_done.notify = register_smram_listener; + qemu_add_machine_init_done_notifier(&smram_machine_done); + } + +This was fixed in commit 8f54bbd0b4 "x86: Check for machine state object class before typecasting it". + diff --git a/results/classifier/105/KVM/1860759 b/results/classifier/105/KVM/1860759 new file mode 100644 index 00000000..67617566 --- /dev/null +++ b/results/classifier/105/KVM/1860759 @@ -0,0 +1,150 @@ +KVM: 0.790 +vnc: 0.759 +mistranslation: 0.721 +other: 0.713 +device: 0.615 +graphic: 0.612 +network: 0.581 +instruction: 0.580 +boot: 0.566 +semantic: 0.565 +socket: 0.548 +assembly: 0.548 + +[REGRESSION] option `-snapshot` ignored with blockdev + +After upgrade of qemu 3.1.0 → 4.2.0 I found that running with libvirt doesn't honor `-snapshot` option anymore. I.e. disk images get modified. +Using `-hda` option honors `-snapshot` + +So I made a test case without libvirt. Testcase using 4.2.0: + +> qemu -hda tmp-16G.img -cdrom regular-rescue-latest-x86_64.iso -m 2G + +This works fine and tmp-16G.img stays unmodified. + +But: +> /usr/bin/qemu-system-x86_64 -name guest=test-linux,debug-threads=on -S -machine pc-i440fx-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,xsaveopt=on,pdpe1gb=on,abm=on -m 2048 -overcommit mem-lock=off -smp 3,sockets=3,cores=1,threads=1 -uuid d32a9191-f51d-4fae-a419-b73d85b49198 -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -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 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/regular-rescue-latest-x86_64.iso\",\"node-name\":\"libvirt-2-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-2-format\",\"read-only\":true,\"driver\":\"raw\",\"file\":\"libvirt-2-storage\"} -device ide-cd,bus=ide.0,unit=0,drive=libvirt-2-format,id=ide0-0-0,bootindex=1 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/tmp-2G.img\",\"node-name\":\"libvirt-1-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-1-format\",\"read-only\":false,\"driver\":\"qcow2\",\"file\":\"libvirt-1-storage\",\"backing\":null} -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-1-format,id=virtio-disk0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:d8:29,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -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=0x6 -snapshot -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +This modifies tmp-16G.img. + +JFYI, I know that snapshot=on option should be used. But `-snapshot` option exists and must work. +Also libvirt doesn't yet support it: https://bugzilla.redhat.com/show_bug.cgi?id=508662 + + +Hi, + +I don’t know much about libvirt, but I would have thought that any manual modification of the qemu command line isn’t supported and might always break. + +Anyway, from a QEMU POV, -snapshot only works with -drive (this includes -hda, etc.). It doesn’t work with -blockdev. I can see that this isn’t documented for -snapshot, but basically whenever -blockdev is used, the user assumes full responsibility for the block graph (or at least that particular subgraph). We cannot enable snapshot functionality then. + +So this can’t be fixed in qemu, as -snapshot doesn’t make sense for -blockdev. This behavior should be documented, though. + +As for libvirt, I don’t know. I would be surprised if it had a guarantee for keeping manual qemu command line additions working, and I can’t imagine that it would scan the XML for “legacy” qemu parameters and interpret them itself (which it would need to do to keep -snapshot working for -blockdev). + +Max + +Max, thanks a lot for the explanation. +Do you mean that snapshot-ing isn't possible totally for blockdev? Then I +guess some libvirt users are in trouble :(( +Actually I didn't quite caught the reason why a blockdev supports backing +but not {backing to a file on /tmp then promptly deleted} ? What's the +technical difference? + + +On 1/24/20 4:41 AM, Ildar wrote: +> Max, thanks a lot for the explanation. +> Do you mean that snapshot-ing isn't possible totally for blockdev? Then I +> guess some libvirt users are in trouble :(( +> Actually I didn't quite caught the reason why a blockdev supports backing +> but not {backing to a file on /tmp then promptly deleted} ? What's the +> technical difference? +> + +On 1/24/20 4:05 AM, Max Reitz wrote: +> +> +> I don’t know much about libvirt, but I would have thought that any +> manual modification of the qemu command line isn’t supported and might +> always break. +> +> Anyway, from a QEMU POV, -snapshot only works with -drive (this includes +> -hda, etc.). It doesn’t work with -blockdev. I can see that this isn’t +> documented for -snapshot, but basically whenever -blockdev is used, the +> user assumes full responsibility for the block graph (or at least that +> particular subgraph). We cannot enable snapshot functionality then. + +Libvirt has never produced a qemu command line containing '-snapshot'. +Part of this is that libvirt wants to control SELinux settings, and +letting qemu create a temporary overlay in /tmp in order to implement +-snapshot does not play nicely with libvirt pre-creating all files that +qemu is allowed to access. + +The fact that you were able to manually add -snapshot to your qemu +command line with older libvirt using -drive (I'm assuming you were also +not using libvirt's SELinux support, because if you were, qemu would +have been unable to create/access the temporary wrapper in /tmp), is a +nice hack. But since modern qemu has declared -snapshot to be +unsupported with -blockdev, and modern libvirt has switched to +-blockdev, I claim that this is not a qemu bug, but a libvirt feature +request. + +That said, libvirt has had a vision for a design for implementing the +equivalent of -drive -snapshot: the <transient/> sub-element added to +the domain/disk/source/driver element has been documented for a long time: + +https://libvirt.org/formatdomain.html +"transient + If present, this indicates that changes to the device contents +should be reverted automatically when the guest exits. With some +hypervisors, marking a disk transient prevents the domain from +participating in migration or snapshots. Since 0.9.5 " + +However, no one has yet implemented it for libvirt's qemu driver. Part +of our reluctance has been that we knew that implementing it would +require libvirt to precreate the wrapper file on every guest start, and +it is only very recently that we've even had enough functionality in +libvirt's qemu driver coupled with new qemu commands to create qcow2 +images using QMP rather than having to shell out to qemu-img. And part +of it is that there was no point in implementing something to work with +-drive, when we knew we had to rework everything for -blockdev anyways. +But now that the work in libvirt to switch to -blockdev is done, it +should be a lot easier to implement PROPER support for the <transient/> +tag, at least for -blockdev usage. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Thank a lot for the detailed answer. Surely it's worth discussing qemu here +leaving libvirt for RH bugzilla. + +> But since modern qemu has declared -snapshot to be unsupported with +-blockdev, and modern libvirt has switched to -blockdev, I claim that this +is not a qemu bug, but a libvirt feature request. + +I'm convinced this isn't qemu's bug. And everything you wrote is +well-justified. Yet, one question left unanswered: +> Do you mean that snapshot-ing isn't possible totally for blockdev? +> Actually I didn't quite caught the reason why a blockdev supports backing +but not {backing to a file on /tmp then promptly deleted} ? What's the +technical difference? + +Thanks! + + +Hi, + +The technical difference is that -blockdev requires you (the user or management software) to create all block graph nodes explicitly. -drive snapshot=on implicitly creates a qcow2 node above the actual disk image (and that node points to a temporary image in /tmp). So because it’s implicit and not explicit, it can’t work with -blockdev. + +With -blockdev, the user has to create this temporary overlay, open it in qemu (with blockdev-add or -blockdev), and then delete it. + +Max + +this answers the whole question. Thanks a lot. closing + + +Internal implementation details aside, from the user PoV it is a *very* serious issue. If -snapshot can't be applied automatically, maybe qemu should warn or better fail if -snapshot is used together with -blockdev. + diff --git a/results/classifier/105/KVM/1862874 b/results/classifier/105/KVM/1862874 new file mode 100644 index 00000000..7c2714e0 --- /dev/null +++ b/results/classifier/105/KVM/1862874 @@ -0,0 +1,118 @@ +KVM: 0.877 +other: 0.827 +mistranslation: 0.802 +graphic: 0.801 +instruction: 0.793 +device: 0.785 +vnc: 0.774 +boot: 0.763 +assembly: 0.751 +semantic: 0.750 +network: 0.744 +socket: 0.730 + +java may stuck for a long time in system mode with "-cpu max" + +Bug Description: +Run "java -version" in guest VM, java may stuck for a long time (several hours) and then recover. + +Steps to reproduce: +1. Launch VM by attached simple script: launch.sh +2. Execute "java -version" and then print "date" in a loop + while : + do + /home/bot/jdk/bin/java -version + date + done +3. A long time gap will be observed: may > 24 hours. + +Technical details: +* host: x86_64 Linux 4.15.0-70-generic +* qemu v4.2.0 +* java: tried two versions: openjdk-11-jre-headless or compiled java-13 +* command-line: (See details in launch.sh) +/home/bot/qemu/qemu-build/qemu-4.2.0/binaries/bin/qemu-system-x86_64 \ + -drive "file=${img},format=qcow2" \ + -drive "file=${user_data},format=raw" \ + -cpu max \ + -m 24G \ + -serial mon:stdio \ + -smp 8 \ + -nographic \ +; + +* Observed by java core dump generated by "kill -SIGSEGV" when java stucked: +Different pthreads are blocked on their own condition variables: + + Id Target Id Frame + 1 Thread 0x7f48a041a080 (LWP 22470) __GI_raise (sig=sig@entry=6) + at ../sysdeps/unix/sysv/linux/raise.c:51 + 2 Thread 0x7f487197d700 (LWP 22473) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f48980197c0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 3 Thread 0x7f4861b89700 (LWP 22483) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4861b88960, expected=0, + futex_word=0x7f489801b084) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 4 Thread 0x7f4861e8c700 (LWP 22480) 0x00007f489f5c76d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f48980107c0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 + 5 Thread 0x7f4861c8a700 (LWP 22482) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4861c89800, expected=0, + futex_word=0x7f489801ed44) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 6 Thread 0x7f48a0418700 (LWP 22471) 0x00007f4880b13200 in ?? () + 7 Thread 0x7f48703ea700 (LWP 22478) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f489801dfc0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 8 Thread 0x7f48702e9700 (LWP 22479) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f489838cd84) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 9 Thread 0x7f4870f71700 (LWP 22475) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f489801a300) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 10 Thread 0x7f487187b700 (LWP 22474) 0x00007f489f5c76d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f48980cf770) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 + 11 Thread 0x7f4871a7f700 (LWP 22472) 0x00007f489f5c76d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f489809ba30) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 + 12 Thread 0x7f4861d8b700 (LWP 22481) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4861d8a680, expected=0, + futex_word=0x7f489801ed44) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 13 Thread 0x7f48704ec700 (LWP 22477) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f48704eb910, expected=0, + futex_word=0x7f489801d120) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 14 Thread 0x7f4870e6f700 (LWP 22476) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4870e6eb20, expected=0, + futex_word=0x7f489828abd0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + + + +Have you tried with KVM ("-M accel=kvm")? + +Please try "strace -o /var/tmp/java.log -f java -version" and upload the strace. If the strace is very large, it's probably safe to remove everything after around 10 seconds. + +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/105/KVM/1863819 b/results/classifier/105/KVM/1863819 new file mode 100644 index 00000000..e0e5b851 --- /dev/null +++ b/results/classifier/105/KVM/1863819 @@ -0,0 +1,59 @@ +KVM: 0.931 +graphic: 0.916 +instruction: 0.916 +other: 0.894 +semantic: 0.848 +assembly: 0.769 +socket: 0.761 +vnc: 0.739 +device: 0.711 +network: 0.688 +mistranslation: 0.657 +boot: 0.520 + +repeated KVM single step crashes leaks into SMP guest and crashes guest application + +Guest: Windows 7 x64 +Host: Ubuntu 18.04.4 (kernel 5.3.0-40-generic) +QEMU: master 6c599282f8ab382fe59f03a6cae755b89561a7b3 + +If I try to use GDB to repeatedly single-step a userspace process while running a KVM guest, the userspace process will eventually crash with a 0x80000004 exception (single step). This is easily reproducible on a Windows guest, I've not tried another guest type but I've been told it's the same there also. + +On a Ubuntu 16 host with an older kernel, this will hang the entire machine. However, it seems it may have been fixed by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cc244a20b86090c087073c124284381cdf47234 ? + +It's not clear to me whether this is a KVM or a QEMU bug. A TCG guest does not crash the userspace process in the same way, but it does hang the VM. + +I've tried a variety of QEMU versions (3.0, 4.2, master) and they all exhibit the same behavior. I'm happy to dig into this more if someone can point me in the right direction. + +Here's the outline for reproducing the bug: + +* Compile iloop.cpp (attached) as a 32-bit application using MSVC +* Start Windows 7 x64 guest under GDB + * Pass '-enable-kvm -smp 4,cores=2 -gdb tcp::4567' to QEMU along with other typical options + +(need to get CR3 to ensure we're in the right application context -- if there's an easier way to do this I'd love to hear it!) +* Install WinDBG on guest +* Copy SysInternals LiveKD to guest +* Start iloop.exe in guest, note loop address +* Run LiveKD from administrative prompt + * livekd64.exe -w +* In WinDBG: + * !process 0 0 + * Search for iloop.exe, note DirBase (this is CR3) + +In GDB: +* Execute 'target remote tcp::4567' +* Execute 'c' +* Hit CTRL-C to pause the VM +* Execute 'p/x $cr3' + .. continue if not equal to DirBase in WinDBG, keep stopping until it is equal +* Once $cr3 is correct value, if you 'stepi' a few times you'll note the process going in a loop, it should keep hitting the address echoed to the console by iloop.exe + +Crash the process from GDB: +* Execute 'stepi 100000000' +* Watch the process, eventually it'll die with an 0x80000004 error + + + +Some experimentation with newer kernels indicate that this is most likely a KVM bug. + diff --git a/results/classifier/105/KVM/1865160 b/results/classifier/105/KVM/1865160 new file mode 100644 index 00000000..8598e267 --- /dev/null +++ b/results/classifier/105/KVM/1865160 @@ -0,0 +1,92 @@ +KVM: 0.911 +semantic: 0.904 +graphic: 0.891 +instruction: 0.887 +assembly: 0.872 +other: 0.872 +boot: 0.796 +vnc: 0.794 +device: 0.780 +socket: 0.708 +mistranslation: 0.683 +network: 0.636 + +Unpredictable behaviour resulting in User process faults + +An example of the behaviour can be reproduced when using NPM, whereby running the command multiple times will result in a variety of error conditions causing the command to fail: + +Example of failure: + +Segmentation fault.] / rollbackFailedOptional: verb npm-session 1a805a5e0ff7b8f5 + +[ 3144.216869] User process fault: interruption code 0038 ilc:3 +[ 3144.216981] Failing address: 66616c7365000000 TEID: 66616c7365000800 +[ 3144.217009] Fault in primary space mode while using user ASCE. +[ 3144.217055] AS:00000000ed28c1c7 R3:0000000000000024 + +Feb 28 14:32:08 qemus390x kernel: [ 3144.216869] User process fault: interruption code 0038 ilc:3 +Feb 28 14:32:08 qemus390x kernel: [ 3144.216981] Failing address: 66616c7365000000 TEID: 66616c7365000800 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217009] Fault in primary space mode while using user ASCE. +Feb 28 14:32:08 qemus390x kernel: [ 3144.217055] AS:00000000ed28c1c7 R3:0000000000000024 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217217] CPU: 2 PID: 1018 Comm: npm Not tainted 4.15.0-88-generic #88-Ubuntu +Feb 28 14:32:08 qemus390x kernel: [ 3144.217234] Hardware name: QEMU 2964 QEMU (KVM/Linux) +Feb 28 14:32:08 qemus390x kernel: [ 3144.217257] User PSW : 00000000185db982 00000000c1d5a1a1 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217290] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217322] User GPRS: 000002aa03705200 0000006a16d73ac1 0000003da4b829f1 0000000000000000 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217343] 0000003da4b82a08 0000003da4b82a08 000002aa036a92ec 0000000000000000 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217364] 0000003da4b829f1 000003ffdb8f7e50 0000003da4b82a08 000003ffdb8f7d88 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217385] 66616c7365000000 000002aa036a05b0 000002aa015bcfb2 000003ffdb8f7d88 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] User Code:#0000006a16d73b00: c0f4000000df brcl 15,0000006a16d73cbe +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] >0000006a16d73b06: a7290000 lghi %r2,0 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b0a: 07fe bcr 15,%r14 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b0c: c02f000001f3 llilf %r2,499 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b12: e3d0dff8ff71 lay %r13,-8(%r13) +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b18: e320d0000024 stg %r2,0(%r13) +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b1e: c028000002aa iihf %r2,682 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217724] Last Breaking-Event-Address: +Feb 28 14:32:08 qemus390x kernel: [ 3144.217759] [<000002aa015bcfae>] 0x2aa015bcfae + + + + +QEMU emulator version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +QEMU Command: + +sudo qemu-system-s390x -smp cpus=5 -machine s390-ccw-virtio -cpu max,zpci=on -serial telnet::4441,server -display none -m 4096 -net nic -net tap -drive file=ubuntu.root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-ccw,devno=fe.0.0003,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=100,scsi=off -drive file=ubuntu.home,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1,scsi=off -drive file=ubuntu.swap,if=none,id=drive-virtio-disk4,format=raw,cache=none -device virtio-blk-ccw,devno=fe.0.0005,drive=drive-virtio-disk4,id=virtio-disk4,bootindex=101,scsi=off + + +Ubuntu 18.04.4 LTS qemus390x ttysclp0 + +Recreate with 20.04 LTS (GNU/Linux 5.4.0-26-generic s390x) + + +May 6 16:14:47 qemu2004 kernel: [86269.521861] User process fault: interruption code 0038 ilc:1 +May 6 16:14:47 qemu2004 kernel: [86269.521943] Failing address: 6563746de40b6000 TEID: 6563746de40b6800 +May 6 16:14:47 qemu2004 kernel: [86269.521961] Fault in primary space mode while using user ASCE. +May 6 16:14:47 qemu2004 kernel: [86269.521994] AS:00000001cc8581c7 R3:0000000000000024 +May 6 16:14:47 qemu2004 kernel: [86269.522113] CPU: 2 PID: 19249 Comm: npm Not tainted 5.4.0-26-generic #30-Ubuntu +May 6 16:14:47 qemu2004 kernel: [86269.522127] Hardware name: QEMU 2964 QEMU (KVM/Linux) +May 6 16:14:47 qemu2004 kernel: [86269.522145] User PSW : 0705200180000000 6563746de40b6167 +May 6 16:14:47 qemu2004 kernel: [86269.522173] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 +May 6 16:14:47 qemu2004 kernel: [86269.522198] User GPRS: 0000000000000000 000000edc8ef86a1 6563746de40b6167 0000000000000000 +May 6 16:14:47 qemu2004 kernel: [86269.522214] 0000000001cfb968 00000004e40b6164 0000000001cfedec 00000004e40b6100 +May 6 16:14:47 qemu2004 kernel: [86269.522230] 0000000001cf60b0 000003fff32fbfb0 00000004e40b60e9 000003fff32fbee0 +May 6 16:14:47 qemu2004 kernel: [86269.522246] 0000000000000004 00000004e40b616c 000003ffaeb7c5a4 000003fff32fbe70 +May 6 16:14:47 qemu2004 kernel: [86269.522335] User Code: Bad PSW. +May 6 16:14:47 qemu2004 kernel: [86269.522350] Last Breaking-Event-Address: +May 6 16:14:47 qemu2004 kernel: [86269.522380] [<000000edc8ef8a28>] 0xedc8ef8a28 + + +Segmentation fault.] - rollbackFailedOptional: verb npm-session 6b1c07499474304d + + + +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/197 + + diff --git a/results/classifier/105/KVM/1873340 b/results/classifier/105/KVM/1873340 new file mode 100644 index 00000000..6a2af268 --- /dev/null +++ b/results/classifier/105/KVM/1873340 @@ -0,0 +1,39 @@ +KVM: 0.944 +device: 0.832 +socket: 0.749 +boot: 0.631 +vnc: 0.604 +graphic: 0.595 +other: 0.470 +semantic: 0.406 +network: 0.397 +mistranslation: 0.378 +instruction: 0.377 +assembly: 0.260 + +KVM Old ATI(pre) AMD card passthrough is not working + +Hello, +tried to passthroug old ATI pre AMD PCI / PCI-E cards, on machine where anything else is working - Nvidia /Matrox / 3dfx cards.. + +Here are results: +ATI Mach 64 PCI - videocard - machine start segfault +ATI Rage XL PCI - videocard - machine start segfault +ATI Radeon 7000 PCI - Segmentation fault +ATI X600 Giabyte GV-RX60P128D - Segmentation fault +ATI X700 PCI-E Legend - videocard - completely broken picture from boot +ATI X800 XL PCI-E Gigabyte - videocard - completely broken picture from boot + All cards has last bioses. + +ATI X600 - HP one professional with DMS-59 connector, im unable to make passthrough, but im not able to set in Windows 98/WinXP machine.. anything less than 16 bit colors.. Im getting VM crashes or boot freezes, when i try to boot with more colors. + + Qemu 2.11 and 4.2, is the same, Mint Linux 19.3. + + +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/252 + + diff --git a/results/classifier/105/KVM/1873344 b/results/classifier/105/KVM/1873344 new file mode 100644 index 00000000..fae81ebd --- /dev/null +++ b/results/classifier/105/KVM/1873344 @@ -0,0 +1,34 @@ +KVM: 0.898 +device: 0.715 +vnc: 0.537 +socket: 0.422 +boot: 0.417 +other: 0.407 +semantic: 0.392 +graphic: 0.373 +mistranslation: 0.347 +instruction: 0.238 +network: 0.235 +assembly: 0.119 + +KVM Windows 98 sound card passthrough is not working for DOS programs.. + +Hello, +im trying to passthrough PCI soundcards into Qemu Windows 98 machine - i tried Yamaha 724/744 and Aunreal Vortex 1, for Windows 98 its working fine, but for Windows 98 dosbox mode its at the best half - working - FM (music) only or nothing with detected by games sound setups. + All there cards are using SB emulation devices. + + When i try to boot to pure DOS, without Windows 98, even music is not working with pass through, only sound which i was able to heard its form Yamaha Setup utility test - Native 16bit sound, aby other test, games setup etc.. are able to dettect sound cards at all. + Im pretty sure that drivers are setup correctly, because im using same setup on other physical machine, when its working. My suspect is missing or broken Qemu MB DMA channels emulation.. Because its is need to make DOS sound working. + + Im using pass through because, SB16 emulation in Qemu is incomplete and for Windows 98 dos box, problem is same as with physical cards. Same with AC97 emulation and its Win95 drivers, which have SB emulation device fallback.. + +Qemu 2.11 + 4.2 Linux Mint 19.3. MB Gigabyte Z170. + + +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/73 + + diff --git a/results/classifier/105/KVM/1874888 b/results/classifier/105/KVM/1874888 new file mode 100644 index 00000000..2208e1e5 --- /dev/null +++ b/results/classifier/105/KVM/1874888 @@ -0,0 +1,113 @@ +KVM: 0.886 +other: 0.870 +vnc: 0.863 +mistranslation: 0.862 +instruction: 0.849 +assembly: 0.846 +device: 0.841 +semantic: 0.831 +boot: 0.814 +graphic: 0.800 +network: 0.777 +socket: 0.775 + +certain programs make QEMU crash with "tcg fatal error" + +The following code snippet crashes qemu with + +.../tcg/tcg.c:3279: tcg fatal error +qemu-x86_64: /usr/local/google/home/kostik/qemu-5.0.0-rc4/accel/tcg/cpu-exec.c:701: int cpu_exec(CPUState *): Assertion `!have_mmap_lock()' failed. + +================ +int main() { + /* +00000000 <.data>: + 0: 2e 45 71 ff cs rex.RB jno 0x3 + 4: e9 00 00 f0 00 jmp 0xf00009 + 9: c4 42 7d 31 3e vpmovzxbd ymm15,QWORD PTR [r14] + e: c4 a3 7d 08 64 82 44 vroundps ymm4,YMMWORD PTR [rdx+r8*4+0x44],0x0 + 15: 00 + 16: 0f 1e 0a nop DWORD PTR [rdx] + 19: 43 0f ec 20 rex.XB paddsb mm4,QWORD PTR [r8] + 1d: 66 47 0f 3a 0c 3d 00 rex.RXB blendps xmm15,XMMWORD PTR [rip+0x8000],0x0 # 0x8028 + 24: 80 00 00 00 + 28: c4 e3 f9 df 5f 86 0d vaeskeygenassist xmm3,XMMWORD PTR [rdi-0x7a],0xd + 2f: c4 e2 55 92 74 fc 0a vgatherdps ymm6,DWORD PTR [rsp+ymm7*8+0xa],ymm5 + 36: c4 e2 f9 17 9a 01 00 vptest xmm3,XMMWORD PTR [rdx+0x1] + 3d: 00 00 +*/ + char buf[] = { + 0x2E, 0x45, 0x71, 0xFF, 0xE9, 0x00, 0x00, 0xF0, 0x00, 0xC4, 0x42, 0x7D, 0x31, 0x3E, 0xC4, 0xA3, 0x7D, 0x08, 0x64, 0x82, 0x44, 0x00, 0x0F, 0x1E, 0x0A, 0x43, 0x0F, 0xEC, 0x20, 0x66, 0x47, 0x0F, 0x3A, 0x0C, 0x3D, 0x00, 0x80, 0x00, 0x00, 0x00, 0xC4, 0xE3, 0xF9, 0xDF, 0x5F, 0x86, 0x0D, 0xC4, 0xE2, 0x55, 0x92, 0x74, 0xFC, 0x0A, 0xC4, 0xE2, 0xF9, 0x17, 0x9A, 0x01, 0x00, 0x00, 0x00 + }; + void (*f)(void) = (void (*) (void))buf; + f(); + return 0; +} +================ +Steps to reproduce: +1) clang -static repro.c -o repro +2) qemu-x86_64-static repro + +Tested with 4.2.0 and 5.0.0-rc4. Both -user and -system variants are affected. + +A few more snippets that cause the same sort of behavior: +1) 0x64, 0x46, 0x7D, 0xFF, 0xDF, 0x27, 0x46, 0x0F, 0xD4, 0x83, 0x5E, 0x00, 0x00, 0x00, 0x3E, 0x0F, 0x6A, 0xEF, 0x0F, 0x05, 0xC4, 0x42, 0xFD, 0x1E, 0xCF, 0x46, 0x18, 0xE3, 0x47, 0xCD, 0x4E, 0x6E, 0x0F, 0x0F, 0x16, 0x8A + +2) 0x67, 0x45, 0xDB, 0xD0, 0xAA, 0xC4, 0xE2, 0xB1, 0x01, 0x57, 0x00, 0xF3, 0x6F, 0xF3, 0x42, 0x0F, 0x1E, 0xFD, 0x64, 0x2E, 0xF2, 0x45, 0xD9, 0xC4, 0x3E, 0xF3, 0x0F, 0xAE, 0xF4, 0x3E, 0x47, 0x0F, 0x1C, 0x22, 0x42, 0x73, 0xFF, 0xD9, 0xFD + +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.] + +Running with '-d in_asm' under gdb I get: + +---------------- +IN: +0x40007feef0: 2e 45 71 ff jno 0x40007feef3 + +---------------- +IN: +0x40007feef3: ff .byte 0xff +0x40007feef4: e9 .byte 0xe9 + + +Thread 1 "qemu-x86_64" received signal SIGILL, Illegal instruction. + +Thomas, could you migrate this to bug gitlab issues please? + + +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/683 + + diff --git a/results/classifier/105/KVM/1877052 b/results/classifier/105/KVM/1877052 new file mode 100644 index 00000000..4596e111 --- /dev/null +++ b/results/classifier/105/KVM/1877052 @@ -0,0 +1,61 @@ +KVM: 0.954 +other: 0.943 +graphic: 0.873 +boot: 0.871 +semantic: 0.784 +mistranslation: 0.674 +device: 0.614 +instruction: 0.540 +vnc: 0.504 +socket: 0.459 +network: 0.454 +assembly: 0.345 + +KVM Win 10 guest pauses after kernel upgrade + + + +Hello! +Unfortunately the bug has apparently reappeared. I have a Windows 10 running in a VM, which after my today's "apt upgrade" goes into pause mode after a few seconds of running time. + +Until yesterday it used to work and I was able to boot the VM. During the kernel update (from 5.4.0-28.33 to 5.4.0-29.34) the VM was active and then went into pause mode. Even after a reboot of my host system the problem still persists: the VM boots for a few seconds and then switches to pause mode. + + +Kind regards, + Andreas + + + + + + + + + +Note: might be related (or not) to bug 1866870 +Let's analyze as independent and dup if it turns out to be a dup. + +The warnings in the report like "MSR(48FH).vmx-exit-load-perf-global-ctrl" are unrelated (in regard to guest hang). +Those happen on +a) too old kernels that don't support the feature +b) mismatch of expectations of a chips vs its actual capabilities +E.g. if libvirt thinks a feature should be supported by a chip, but isn't. +There are toomany SKUs out there to be perfect - so these are red-herrings at best. + +I have not seen similar reports recently nor anyone else chiming in on this one. +After loosing what e thought could be a track to the bgu I'm puzzled what to do now on this? + +@Andreas - did you in the meantime find any new insight on this? + +@Andreas - If we find nothing else to try I'll ping you when I have a newer qemu&libvirt build for Ubuntu 20.10 for you to try. + +I haven't seen any similar reports nor any updates here. +Might I ask if you have got any further since then? + +Qemu 5.0 is available in Ubuntu 20.10 now, if you are willing to upgrade or install a test system that might be worth a try (new libvirt is still WIP, but unlikely to play a role here). +20.10 proposed would even have a 5.8.0.12.14 kernel since a kernel change might have been what started this that might be worth a check as well. + +[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/105/KVM/1878250 b/results/classifier/105/KVM/1878250 new file mode 100644 index 00000000..ac62cec8 --- /dev/null +++ b/results/classifier/105/KVM/1878250 @@ -0,0 +1,67 @@ +KVM: 0.936 +other: 0.928 +vnc: 0.925 +instruction: 0.918 +assembly: 0.907 +graphic: 0.905 +mistranslation: 0.902 +semantic: 0.901 +device: 0.895 +network: 0.889 +boot: 0.887 +socket: 0.885 + +Assertion failure in iov_from_buf_full through the e1000e + +Hello, +While fuzzing, I found an input that triggers an assertion failure in +iov_from_buf_full through the e1000e: + +size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t): Assertion `offset == 0' failed. + + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x5555570c74c0 <str> "offset == 0", file=0x5555570c7500 <str> "/home/alxndr/Development/qemu/util/iov.c", line=0x28, function=0x5555570c7560 <__PRETTY_FUNCTION__.iov_from_buf_full> "size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t)") at assert.c:101 +#4 0x0000555556c5fa5e in iov_from_buf_full (iov=<optimized out>, iov_cnt=<optimized out>, offset=<optimized out>, buf=buf@entry=0x7fffffffbb60, bytes=<optimized out>, bytes@entry=0x2) at /home/alxndr/Development/qemu/util/iov.c:40 +#5 0x00005555565f585e in iov_from_buf (iov=0x7fffffffb830, iov_cnt=0xffffb830, offset=0x0, buf=0x7fffffffbb60, bytes=0x2) at /home/alxndr/Development/qemu/include/qemu/iov.h:49 +#6 0x00005555565f585e in net_tx_pkt_update_ip_checksums (pkt=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:139 +#7 0x0000555556621f9c in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:638 +#8 0x0000555556621f9c in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +#9 0x0000555556621f9c in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#10 0x0000555556621f9c in e1000e_start_xmit (core=<optimized out>, txr=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#11 0x000055555661edb1 in e1000e_set_tdt (core=0x7fffffffb830, index=0xe06, val=0x563) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#12 0x000055555660f2cd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#13 0x00005555560028d7 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe10207e8 0x14 0x00002d05225f3f5f5e00000200000000250013ff +write 0x200006a 0xc 0x08004500feffffff02007b06 +write 0xe1020098 0x3a2 0x000006ffdf054e411b0002e10000000006ffe1054e411b0002e10000000006ffe3054e411b0002e10000000006ffe5054e411b0002e10000000006ffe7054e411b0002e10000000006ffe9054e411b0002e10000000006ffeb054e411b0002e10000000006ffed054e411b0002e10000000006ffef054e411b0002e10000000006fff1054e411b0002e10000000006fff3054e411b0002e10000000006fff5054e411b0002e10000000006fff7054e411b0002e10000000006fff9054e411b0002e10000000006fffb054e411b0002e10000000006fffd054e411b0002e10000000006ffff054e411b0002e10000000006ff01054e411b0002e10000000006ff03054e411b0002e10000000006ff05054e411b0002e10000000006ff07054e411b0002e10000000006ff09054e411b0002e10000000006ff0b054e411b0002e10000000006ff0d054e411b0002e10000000006ff0f054e411b0002e10000000006ff11054e411b0002e10000000006ff13054e411b0002e10000000006ff15054e411b0002e10000000006ff17054e411b0002e10000000006ff19054e411b0002e10000000006ff1b054e411b0002e10000000006ff1d054e411b0002e10000000006ff1f054e411b0002e10000000006ff21054e411b0002e10000000006ff23054e411b0002e10000000006ff25054e411b0002e10000000006ff27054e411b0002e10000000006ff29054e411b0002e10000000006ff2b054e411b0002e10000000006ff2d054e411b0002e10000000006ff2f054e411b0002e10000000006ff31054e411b0002e10000000006ff33054e411b0002e10000000006ff35054e411b0002e10000000006ff37054e411b0002e10000000006ff39054e411b0002e10000000006ff3b054e411b0002e10000000006ff3d054e411b0002e10000000006ff3f054e411b0002e10000000006ff41054e411b0002e10000000006ff43054e411b0002e10000000006ff45054e411b0002e10000000006ff47054e411b0002e10000000006ff49054e411b0002e10000000006ff4b054e411b0002e10000000006ff4d054e411b0002e10000000006ff4f054e411b0002e10000000006ff51054e411b0002e10000000006ff53054e411b0002e10000000006ff55054e411b0002e10000000006ff57054e411b0002e10000000006ff59054e411b0002e10000000006ff5b054e411b0002e10000000006ff5d054e411b0002e10000000006ff5f054e411b0002e10000000006ff61054e411b0002e10000000006ff6305 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex + + + +This still triggers with current QEMU development version ... marking as "Confirmed" ... Alexander, could you please move this ticket to the new issue tracker at gitlab? + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/535 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/105/KVM/1878642 b/results/classifier/105/KVM/1878642 new file mode 100644 index 00000000..b47b4f71 --- /dev/null +++ b/results/classifier/105/KVM/1878642 @@ -0,0 +1,70 @@ +KVM: 0.847 +other: 0.840 +vnc: 0.817 +mistranslation: 0.805 +graphic: 0.802 +device: 0.783 +instruction: 0.782 +semantic: 0.779 +network: 0.776 +socket: 0.772 +assembly: 0.759 +boot: 0.722 + +Assertion failure in pci_bus_get_irq_level + +Hello, +I found an input which triggers an assertion failure in pci_bus_get_irq_level: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/pci/pci.c:268: int pci_bus_get_irq_level(PCIBus *, int): Assertion `irq_num < bus->nirq' failed. +Aborted +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff685742f in __assert_fail_base (fmt=0x7ffff69bdb48 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x555557f9bca0 <str> "irq_num < bus->nirq", file=0x555557f9bbe0 <str> "/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=<optimized out>) at assert.c:92 +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557f9bca0 <str> "irq_num < bus->nirq", file=0x555557f9bbe0 <str> "/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=0x555557f9bc40 <__PRETTY_FUNCTION__.pci_bus_get_irq_level> "int pci_bus_get_irq_level(PCIBus *, int)") at assert.c:101 +#4 0x0000555557060c34 in pci_bus_get_irq_level (bus=0x61d000096080, irq_num=0xef) at /home/alxndr/Development/qemu/hw/pci/pci.c:268 +#5 0x0000555556657391 in ich9_lpc_update_apic (lpc=0x62a000006200, gsi=0xff) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:249 +#6 0x0000555556658ea7 in ich9_set_sci (opaque=0x62a000006200, irq_num=0x0, level=0x1) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:354 +#7 0x0000555556ccefc6 in qemu_set_irq (irq=0x60600002af80, level=0x1) at /home/alxndr/Development/qemu/hw/core/irq.c:44 +#8 0x0000555556bc06fd in acpi_update_sci (regs=0x62a000006c80, irq=0x60600002af80) at /home/alxndr/Development/qemu/hw/acpi/core.c:723 +#9 0x0000555556bccb08 in ich9_pm_update_sci_fn (regs=0x62a000006c80) at /home/alxndr/Development/qemu/hw/acpi/ich9.c:56 +#10 0x0000555556bc10ee in acpi_pm_evt_write (opaque=0x62a000006c80, addr=0x2, val=0x2049, width=0x2) at /home/alxndr/Development/qemu/hw/acpi/core.c:456 +#11 0x00005555564938b5 in memory_region_write_accessor (mr=0x62a000006db0, addr=0x2, value=0x7fffffff9c70, size=0x2, shift=0x0, mask=0xffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#12 0x000055555649328a in access_with_adjusted_size (addr=0x2, value=0x7fffffff9c70, size=0x2, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62a000006db0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#13 0x0000555556491df6 in memory_region_dispatch_write (mr=0x62a000006db0, addr=0x2, data=0x2049, op=MO_16, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#14 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033fe0, addr=0x5d02, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x2, l=0x2, mr=0x62a000006db0) at /home/alxndr/Development/qemu/exec.c:3137 +#15 0x00005555562bbad9 in flatview_write (fv=0x606000033fe0, addr=0x5d02, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#16 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0x5d02, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#17 0x0000555556478c0a in cpu_outl (addr=0x5d02, val=0xedf82049) at /home/alxndr/Development/qemu/ioport.c:80 +#18 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ef20) at /home/alxndr/Development/qemu/qtest.c:396 +#19 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#20 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", size=0xe9) at /home/alxndr/Development/qemu/qtest.c:722 +#21 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at /home/alxndr/Development/qemu/chardev/char.c:183 +#22 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at /home/alxndr/Development/qemu/chardev/char.c:195 +#23 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#24 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#25 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#26 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#27 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#28 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#29 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#30 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x8400f841 +outl 0xcfc 0xebed205d +outl 0x5d02 0xedf82049 +EOF + +Please let me know if I can provide any further info. +-Alex + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05564.html + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/KVM/1878645 b/results/classifier/105/KVM/1878645 new file mode 100644 index 00000000..68ec4f69 --- /dev/null +++ b/results/classifier/105/KVM/1878645 @@ -0,0 +1,1074 @@ +KVM: 0.832 +other: 0.823 +vnc: 0.766 +graphic: 0.692 +instruction: 0.677 +device: 0.668 +semantic: 0.650 +mistranslation: 0.650 +assembly: 0.616 +socket: 0.591 +boot: 0.579 +network: 0.564 + +null-ptr dereference in ich9_apm_ctrl_changed + +Hello, +While fuzzing, I found an input which triggers a NULL pointer dereference in +tcg_handle_interrupt. It seems the culprint is a "cpu" pointer - maybe this bug +is specific to QTest? + +==23862==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000b4 (pc 0x55b9dc7c9dce bp 0x7ffc346a0900 sp 0x7ffc346a0880 T0) +==23862==The signal is caused by a READ memory access. +==23862==Hint: address points to the zero page. + #0 0x55b9dc7c9dce in tcg_handle_interrupt /home/alxndr/Development/qemu/accel/tcg/tcg-all.c:57:21 + #1 0x55b9dc904799 in cpu_interrupt /home/alxndr/Development/qemu/include/hw/core/cpu.h:872:5 + #2 0x55b9dc9085e8 in ich9_apm_ctrl_changed /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:442:13 + #3 0x55b9dd19cdc8 in apm_ioport_writeb /home/alxndr/Development/qemu/hw/isa/apm.c:50:13 + #4 0x55b9dc73f8b4 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 + #5 0x55b9dc73f289 in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 + #6 0x55b9dc73ddf5 in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + #7 0x55b9dc577bf3 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 + #8 0x55b9dc567ad8 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 + #9 0x55b9dc567608 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 + #10 0x55b9dc723fe7 in cpu_outb /home/alxndr/Development/qemu/ioport.c:60:5 + #11 0x55b9dc72d3c0 in qtest_process_command /home/alxndr/Development/qemu/qtest.c:392:13 + #12 0x55b9dc72b186 in qtest_process_inbuf /home/alxndr/Development/qemu/qtest.c:710:9 + #13 0x55b9dc72a8b3 in qtest_read /home/alxndr/Development/qemu/qtest.c:722:5 + #14 0x55b9ddc6e60b in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:183:9 + #15 0x55b9ddc6e75a in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:195:9 + #16 0x55b9ddc77979 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9 + #17 0x55b9ddcff0e9 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12 + #18 0x7f7161eac897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x55b9ddebcb84 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #20 0x55b9ddebb57d in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #21 0x55b9ddebb176 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #22 0x55b9dcb4bd1d in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #23 0x55b9ddd1629c in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #24 0x7f7160a5ce0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #25 0x55b9dc49c819 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xc9c819) + + +I can reproduce this in qemu 5.0 built with AddressSanitizer using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x8400f841 +outl 0xcfc 0xaa215d6d +outl 0x6d30 0x2ef8ffbe +outb 0xb2 0x20 +EOF + +Please let me know if I can provide any further info. +-Alex + +I don't think this is a qtest-specific error: +cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio +o/4 0xcf8 0x8400f841 +o/4 0xcfc 0xaa215d6d +o/4 0x6d30 0x2ef8ffbe +o/1 0xb2 0x20 +EOF + +... +Segmentation fault + + + +Alexander Bulekov <email address hidden> writes: + +> I don't think this is a qtest-specific error: +> cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio +> o/4 0xcf8 0x8400f841 +> o/4 0xcfc 0xaa215d6d +> o/4 0x6d30 0x2ef8ffbe +> o/1 0xb2 0x20 +> EOF +> +> ... +> Segmentation fault + +Both this and the qtest have the same problem of depending on +current_cpu which is a TLS variable which will never be correct from the +qtest or monitor context. There are only a few other cases. + +sun4m:cpu_halt_signal does: + + if (level && current_cpu) { + cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT); + } + +pxa2xx:pxa2xx_pwrmode_write does a bare: + + /* Suspend */ + cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT); + +but given the context has a CPUARMState *env it could arguably use that +to derive current_cpu but as it's only triggered by a system register +write you can't actually trigger from a monitor/qtest command. + +I would suggest either: + + } else if (current_cpu) { + cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); + } + +or possibly: + + } else { + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); + } + +if you really care about triggering a real IRQ from outside the CPU context. + +-- +Alex Bennée + + +On 200629 2000, Alex Bennée wrote: +> +> Alexander Bulekov <email address hidden> writes: +> +> > I don't think this is a qtest-specific error: +> > cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio +> > o/4 0xcf8 0x8400f841 +> > o/4 0xcfc 0xaa215d6d +> > o/4 0x6d30 0x2ef8ffbe +> > o/1 0xb2 0x20 +> > EOF +> > +> > ... +> > Segmentation fault +> +> Both this and the qtest have the same problem of depending on +> current_cpu which is a TLS variable which will never be correct from the +> qtest or monitor context. There are only a few other cases. + +Ah that makes sense. It probably isn't a real issue, but I'll send +patches with the changes you suggested below. +Thank you + +> sun4m:cpu_halt_signal does: +> +> if (level && current_cpu) { +> cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT); +> } +> +> pxa2xx:pxa2xx_pwrmode_write does a bare: +> +> /* Suspend */ +> cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT); +> +> but given the context has a CPUARMState *env it could arguably use that +> to derive current_cpu but as it's only triggered by a system register +> write you can't actually trigger from a monitor/qtest command. +> +> I would suggest either: +> +> } else if (current_cpu) { +> cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +> } +> +> or possibly: +> +> } else { +> cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +> } +> +> if you really care about triggering a real IRQ from outside the CPU context. +> +> -- +> Alex Bennée +> + + +It's possible to trigger this function from qtest/monitor at which +point current_cpu won't point at the right place. Check it and +fall back to first_cpu if it's NULL. + +Signed-off-by: Alex Bennée <email address hidden> +Cc: Bug 1878645 <email address hidden> +--- + hw/isa/lpc_ich9.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +index cd6e169d47a..791c878eb0b 100644 +--- a/hw/isa/lpc_ich9.c ++++ b/hw/isa/lpc_ich9.c +@@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) + cpu_interrupt(cs, CPU_INTERRUPT_SMI); + } + } else { +- cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); ++ cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); + } + } + } +-- +2.20.1 + + + +On 7/1/20 3:56 PM, Alex Bennée wrote: +> It's possible to trigger this function from qtest/monitor at which +> point current_cpu won't point at the right place. Check it and +> fall back to first_cpu if it's NULL. +> +> Signed-off-by: Alex Bennée <email address hidden> +> Cc: Bug 1878645 <email address hidden> +> --- +> hw/isa/lpc_ich9.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +> index cd6e169d47a..791c878eb0b 100644 +> --- a/hw/isa/lpc_ich9.c +> +++ b/hw/isa/lpc_ich9.c +> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +> } +> } else { +> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); + +I'm not sure this change anything, as first_cpu is NULL when using +qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +GDB connection segfault caused by empty machines"). + +> } +> } +> } +> + + + + +Philippe Mathieu-Daudé <email address hidden> writes: + +> On 7/1/20 3:56 PM, Alex Bennée wrote: +>> It's possible to trigger this function from qtest/monitor at which +>> point current_cpu won't point at the right place. Check it and +>> fall back to first_cpu if it's NULL. +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> Cc: Bug 1878645 <email address hidden> +>> --- +>> hw/isa/lpc_ich9.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>> index cd6e169d47a..791c878eb0b 100644 +>> --- a/hw/isa/lpc_ich9.c +>> +++ b/hw/isa/lpc_ich9.c +>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>> } +>> } else { +>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +> +> I'm not sure this change anything, as first_cpu is NULL when using +> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +> GDB connection segfault caused by empty machines"). + +Good point - anyway feel free to ignore - it shouldn't have been in this +series. It was just some random experimentation I was doing when looking +at that bug. + +-- +Alex Bennée + + +On 7/1/20 6:40 PM, Alex Bennée wrote: +> +> Philippe Mathieu-Daudé <email address hidden> writes: +> +>> On 7/1/20 3:56 PM, Alex Bennée wrote: +>>> It's possible to trigger this function from qtest/monitor at which +>>> point current_cpu won't point at the right place. Check it and +>>> fall back to first_cpu if it's NULL. +>>> +>>> Signed-off-by: Alex Bennée <email address hidden> +>>> Cc: Bug 1878645 <email address hidden> +>>> --- +>>> hw/isa/lpc_ich9.c | 2 +- +>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>> +>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>>> index cd6e169d47a..791c878eb0b 100644 +>>> --- a/hw/isa/lpc_ich9.c +>>> +++ b/hw/isa/lpc_ich9.c +>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>>> } +>>> } else { +>>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +>> +>> I'm not sure this change anything, as first_cpu is NULL when using +>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +>> GDB connection segfault caused by empty machines"). +> +> Good point - anyway feel free to ignore - it shouldn't have been in this +> series. It was just some random experimentation I was doing when looking +> at that bug. + +See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without +crashing") for a similar approach, but here I was thinking about +a more generic fix, not very intrusive: + +-- >8 -- +diff --git a/hw/isa/apm.c b/hw/isa/apm.c +index bce266b957..809afeb3e4 100644 +--- a/hw/isa/apm.c ++++ b/hw/isa/apm.c +@@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr +addr, uint64_t val, + if (addr == 0) { + apm->apmc = val; + +- if (apm->callback) { ++ if (apm->callback && !qtest_enabled()) { + (apm->callback)(val, apm->arg); + } + } else { +--- + + + + +Philippe Mathieu-Daudé <email address hidden> writes: + +> On 7/1/20 6:40 PM, Alex Bennée wrote: +>> +>> Philippe Mathieu-Daudé <email address hidden> writes: +>> +>>> On 7/1/20 3:56 PM, Alex Bennée wrote: +>>>> It's possible to trigger this function from qtest/monitor at which +>>>> point current_cpu won't point at the right place. Check it and +>>>> fall back to first_cpu if it's NULL. +>>>> +>>>> Signed-off-by: Alex Bennée <email address hidden> +>>>> Cc: Bug 1878645 <email address hidden> +>>>> --- +>>>> hw/isa/lpc_ich9.c | 2 +- +>>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>>> +>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>>>> index cd6e169d47a..791c878eb0b 100644 +>>>> --- a/hw/isa/lpc_ich9.c +>>>> +++ b/hw/isa/lpc_ich9.c +>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>>>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>>>> } +>>>> } else { +>>>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>>>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +>>> +>>> I'm not sure this change anything, as first_cpu is NULL when using +>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +>>> GDB connection segfault caused by empty machines"). +>> +>> Good point - anyway feel free to ignore - it shouldn't have been in this +>> series. It was just some random experimentation I was doing when looking +>> at that bug. +> +> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without +> crashing") for a similar approach, but here I was thinking about +> a more generic fix, not very intrusive: +> +> -- >8 -- +> diff --git a/hw/isa/apm.c b/hw/isa/apm.c +> index bce266b957..809afeb3e4 100644 +> --- a/hw/isa/apm.c +> +++ b/hw/isa/apm.c +> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr +> addr, uint64_t val, +> if (addr == 0) { +> apm->apmc = val; +> +> - if (apm->callback) { +> + if (apm->callback && !qtest_enabled()) { +> (apm->callback)(val, apm->arg); +> } + +But the other failure mode reported on the bug thread was via the +monitor - so I'm not sure just checking for qtest catches that. + +> } else { +> --- + + +-- +Alex Bennée + + ++Paolo + +On 7/1/20 7:09 PM, Alex Bennée wrote: +> Philippe Mathieu-Daudé <email address hidden> writes: +>> On 7/1/20 6:40 PM, Alex Bennée wrote: +>>> Philippe Mathieu-Daudé <email address hidden> writes: +>>> +>>>> On 7/1/20 3:56 PM, Alex Bennée wrote: +>>>>> It's possible to trigger this function from qtest/monitor at which +>>>>> point current_cpu won't point at the right place. Check it and +>>>>> fall back to first_cpu if it's NULL. +>>>>> +>>>>> Signed-off-by: Alex Bennée <email address hidden> +>>>>> Cc: Bug 1878645 <email address hidden> +>>>>> --- +>>>>> hw/isa/lpc_ich9.c | 2 +- +>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>>>> +>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>>>>> index cd6e169d47a..791c878eb0b 100644 +>>>>> --- a/hw/isa/lpc_ich9.c +>>>>> +++ b/hw/isa/lpc_ich9.c +>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>>>>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>>>>> } +>>>>> } else { +>>>>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>>>>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +>>>> +>>>> I'm not sure this change anything, as first_cpu is NULL when using +>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +>>>> GDB connection segfault caused by empty machines"). +>>> +>>> Good point - anyway feel free to ignore - it shouldn't have been in this +>>> series. It was just some random experimentation I was doing when looking +>>> at that bug. +>> +>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without +>> crashing") for a similar approach, but here I was thinking about +>> a more generic fix, not very intrusive: +>> +>> -- >8 -- +>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c +>> index bce266b957..809afeb3e4 100644 +>> --- a/hw/isa/apm.c +>> +++ b/hw/isa/apm.c +>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr +>> addr, uint64_t val, +>> if (addr == 0) { +>> apm->apmc = val; +>> +>> - if (apm->callback) { +>> + if (apm->callback && !qtest_enabled()) { +>> (apm->callback)(val, apm->arg); +>> } +> +> But the other failure mode reported on the bug thread was via the +> monitor - so I'm not sure just checking for qtest catches that. + +Ah indeed. + +in exec.c: + +/* current CPU in the current thread. It is only valid inside + cpu_exec() */ +__thread CPUState *current_cpu; + +Maybe we shouldn't use current_cpu out of exec.c... + + + +On 7/1/20 7:34 PM, Philippe Mathieu-Daudé wrote: +> +Paolo +> +> On 7/1/20 7:09 PM, Alex Bennée wrote: +>> Philippe Mathieu-Daudé <email address hidden> writes: +>>> On 7/1/20 6:40 PM, Alex Bennée wrote: +>>>> Philippe Mathieu-Daudé <email address hidden> writes: +>>>> +>>>>> On 7/1/20 3:56 PM, Alex Bennée wrote: +>>>>>> It's possible to trigger this function from qtest/monitor at which +>>>>>> point current_cpu won't point at the right place. Check it and +>>>>>> fall back to first_cpu if it's NULL. +>>>>>> +>>>>>> Signed-off-by: Alex Bennée <email address hidden> +>>>>>> Cc: Bug 1878645 <email address hidden> +>>>>>> --- +>>>>>> hw/isa/lpc_ich9.c | 2 +- +>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>>>>> +>>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>>>>>> index cd6e169d47a..791c878eb0b 100644 +>>>>>> --- a/hw/isa/lpc_ich9.c +>>>>>> +++ b/hw/isa/lpc_ich9.c +>>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>>>>>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>>>>>> } +>>>>>> } else { +>>>>>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>>>>>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +>>>>> +>>>>> I'm not sure this change anything, as first_cpu is NULL when using +>>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +>>>>> GDB connection segfault caused by empty machines"). +>>>> +>>>> Good point - anyway feel free to ignore - it shouldn't have been in this +>>>> series. It was just some random experimentation I was doing when looking +>>>> at that bug. +>>> +>>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without +>>> crashing") for a similar approach, but here I was thinking about +>>> a more generic fix, not very intrusive: +>>> +>>> -- >8 -- +>>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c +>>> index bce266b957..809afeb3e4 100644 +>>> --- a/hw/isa/apm.c +>>> +++ b/hw/isa/apm.c +>>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr +>>> addr, uint64_t val, +>>> if (addr == 0) { +>>> apm->apmc = val; +>>> +>>> - if (apm->callback) { +>>> + if (apm->callback && !qtest_enabled()) { +>>> (apm->callback)(val, apm->arg); +>>> } +>> +>> But the other failure mode reported on the bug thread was via the +>> monitor - so I'm not sure just checking for qtest catches that. +> +> Ah indeed. +> +> in exec.c: +> +> /* current CPU in the current thread. It is only valid inside +> cpu_exec() */ +> __thread CPUState *current_cpu; +> +> Maybe we shouldn't use current_cpu out of exec.c... + +I meant, out of cpu_exec(), a cpu thread. Here we access it +from an I/O thread. + + + ++MST/Igor for ICH9 + +On 7/1/20 7:37 PM, Philippe Mathieu-Daudé wrote: +> On 7/1/20 7:34 PM, Philippe Mathieu-Daudé wrote: +>> +Paolo +>> +>> On 7/1/20 7:09 PM, Alex Bennée wrote: +>>> Philippe Mathieu-Daudé <email address hidden> writes: +>>>> On 7/1/20 6:40 PM, Alex Bennée wrote: +>>>>> Philippe Mathieu-Daudé <email address hidden> writes: +>>>>> +>>>>>> On 7/1/20 3:56 PM, Alex Bennée wrote: +>>>>>>> It's possible to trigger this function from qtest/monitor at which +>>>>>>> point current_cpu won't point at the right place. Check it and +>>>>>>> fall back to first_cpu if it's NULL. +>>>>>>> +>>>>>>> Signed-off-by: Alex Bennée <email address hidden> +>>>>>>> Cc: Bug 1878645 <email address hidden> +>>>>>>> --- +>>>>>>> hw/isa/lpc_ich9.c | 2 +- +>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>>>>>> +>>>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>>>>>>> index cd6e169d47a..791c878eb0b 100644 +>>>>>>> --- a/hw/isa/lpc_ich9.c +>>>>>>> +++ b/hw/isa/lpc_ich9.c +>>>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>>>>>>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>>>>>>> } +>>>>>>> } else { +>>>>>>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>>>>>>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +>>>>>> +>>>>>> I'm not sure this change anything, as first_cpu is NULL when using +>>>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +>>>>>> GDB connection segfault caused by empty machines"). +>>>>> +>>>>> Good point - anyway feel free to ignore - it shouldn't have been in this +>>>>> series. It was just some random experimentation I was doing when looking +>>>>> at that bug. +>>>> +>>>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without +>>>> crashing") for a similar approach, but here I was thinking about +>>>> a more generic fix, not very intrusive: +>>>> +>>>> -- >8 -- +>>>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c +>>>> index bce266b957..809afeb3e4 100644 +>>>> --- a/hw/isa/apm.c +>>>> +++ b/hw/isa/apm.c +>>>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr +>>>> addr, uint64_t val, +>>>> if (addr == 0) { +>>>> apm->apmc = val; +>>>> +>>>> - if (apm->callback) { +>>>> + if (apm->callback && !qtest_enabled()) { +>>>> (apm->callback)(val, apm->arg); +>>>> } +>>> +>>> But the other failure mode reported on the bug thread was via the +>>> monitor - so I'm not sure just checking for qtest catches that. +>> +>> Ah indeed. +>> +>> in exec.c: +>> +>> /* current CPU in the current thread. It is only valid inside +>> cpu_exec() */ +>> __thread CPUState *current_cpu; +>> +>> Maybe we shouldn't use current_cpu out of exec.c... +> +> I meant, out of cpu_exec(), a cpu thread. Here we access it +> from an I/O thread. + +ARM and S390X use: + +hw/arm/boot.c:460: ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0)); +hw/arm/virt.c:331: armcpu = ARM_CPU(qemu_get_cpu(0)); +hw/arm/virt.c:549: armcpu = ARM_CPU(qemu_get_cpu(0)); +hw/cpu/a15mpcore.c:69: cpuobj = OBJECT(qemu_get_cpu(0)); +hw/cpu/a9mpcore.c:76: cpuobj = OBJECT(qemu_get_cpu(0)); +target/s390x/cpu_models.c:155: cpu = S390_CPU(qemu_get_cpu(0)); +target/s390x/cpu_models.c:169: cpu = S390_CPU(qemu_get_cpu(0)); +target/s390x/cpu_models.c:184: cpu = S390_CPU(qemu_get_cpu(0)); +target/s390x/cpu_models.c:204: cpu = S390_CPU(qemu_get_cpu(0)); +target/s390x/cpu_models.c:218: cpu = S390_CPU(qemu_get_cpu(0)); + +It seems odd that the ICH9 delivers the SMI on a random core. +Usually the IRQ lines are wired to a particular unit. + + + +On 7/1/20 7:48 PM, Philippe Mathieu-Daudé wrote: +> +MST/Igor for ICH9 +> +> On 7/1/20 7:37 PM, Philippe Mathieu-Daudé wrote: +>> On 7/1/20 7:34 PM, Philippe Mathieu-Daudé wrote: +>>> +Paolo +>>> +>>> On 7/1/20 7:09 PM, Alex Bennée wrote: +>>>> Philippe Mathieu-Daudé <email address hidden> writes: +>>>>> On 7/1/20 6:40 PM, Alex Bennée wrote: +>>>>>> Philippe Mathieu-Daudé <email address hidden> writes: +>>>>>> +>>>>>>> On 7/1/20 3:56 PM, Alex Bennée wrote: +>>>>>>>> It's possible to trigger this function from qtest/monitor at which +>>>>>>>> point current_cpu won't point at the right place. Check it and +>>>>>>>> fall back to first_cpu if it's NULL. +>>>>>>>> +>>>>>>>> Signed-off-by: Alex Bennée <email address hidden> +>>>>>>>> Cc: Bug 1878645 <email address hidden> +>>>>>>>> --- +>>>>>>>> hw/isa/lpc_ich9.c | 2 +- +>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) +>>>>>>>> +>>>>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c +>>>>>>>> index cd6e169d47a..791c878eb0b 100644 +>>>>>>>> --- a/hw/isa/lpc_ich9.c +>>>>>>>> +++ b/hw/isa/lpc_ich9.c +>>>>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg) +>>>>>>>> cpu_interrupt(cs, CPU_INTERRUPT_SMI); +>>>>>>>> } +>>>>>>>> } else { +>>>>>>>> - cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI); +>>>>>>>> + cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI); +>>>>>>> +>>>>>>> I'm not sure this change anything, as first_cpu is NULL when using +>>>>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix +>>>>>>> GDB connection segfault caused by empty machines"). +>>>>>> +>>>>>> Good point - anyway feel free to ignore - it shouldn't have been in this +>>>>>> series. It was just some random experimentation I was doing when looking +>>>>>> at that bug. +>>>>> +>>>>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without +>>>>> crashing") for a similar approach, but here I was thinking about +>>>>> a more generic fix, not very intrusive: +>>>>> +>>>>> -- >8 -- +>>>>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c +>>>>> index bce266b957..809afeb3e4 100644 +>>>>> --- a/hw/isa/apm.c +>>>>> +++ b/hw/isa/apm.c +>>>>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr +>>>>> addr, uint64_t val, +>>>>> if (addr == 0) { +>>>>> apm->apmc = val; +>>>>> +>>>>> - if (apm->callback) { +>>>>> + if (apm->callback && !qtest_enabled()) { +>>>>> (apm->callback)(val, apm->arg); +>>>>> } +>>>> +>>>> But the other failure mode reported on the bug thread was via the +>>>> monitor - so I'm not sure just checking for qtest catches that. +>>> +>>> Ah indeed. +>>> +>>> in exec.c: +>>> +>>> /* current CPU in the current thread. It is only valid inside +>>> cpu_exec() */ +>>> __thread CPUState *current_cpu; +>>> +>>> Maybe we shouldn't use current_cpu out of exec.c... +>> +>> I meant, out of cpu_exec(), a cpu thread. Here we access it +>> from an I/O thread. + +Ah! we are in the monitor thread... It makes sense there is not +current_cpu assigned :) + +> +> ARM and S390X use: +> +> hw/arm/boot.c:460: ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0)); +> hw/arm/virt.c:331: armcpu = ARM_CPU(qemu_get_cpu(0)); +> hw/arm/virt.c:549: armcpu = ARM_CPU(qemu_get_cpu(0)); +> hw/cpu/a15mpcore.c:69: cpuobj = OBJECT(qemu_get_cpu(0)); +> hw/cpu/a9mpcore.c:76: cpuobj = OBJECT(qemu_get_cpu(0)); +> target/s390x/cpu_models.c:155: cpu = S390_CPU(qemu_get_cpu(0)); +> target/s390x/cpu_models.c:169: cpu = S390_CPU(qemu_get_cpu(0)); +> target/s390x/cpu_models.c:184: cpu = S390_CPU(qemu_get_cpu(0)); +> target/s390x/cpu_models.c:204: cpu = S390_CPU(qemu_get_cpu(0)); +> target/s390x/cpu_models.c:218: cpu = S390_CPU(qemu_get_cpu(0)); +> +> It seems odd that the ICH9 delivers the SMI on a random core. +> Usually the IRQ lines are wired to a particular unit. +> + + + +We can run I/O access with the 'i' or 'o' HMP commands in the +monitor. These commands are expected to run on a vCPU. The +monitor is not a vCPU thread. To avoid crashing, initialize +the 'current_cpu' variable with the first vCPU created. The +command executed on the monitor will end using it. + +This fixes: + + $ cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio + o/4 0xcf8 0x8400f841 + o/4 0xcfc 0xaa215d6d + o/4 0x6d30 0x2ef8ffbe + o/1 0xb2 0x20 + EOF + Segmentation fault (core dumped) + + Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. + 0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57 + 57 old_mask = cpu->interrupt_request; + (gdb) bt + #0 0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57 + #1 0x00005555558ed7d2 in cpu_interrupt (cpu=0x0, mask=64) at include/hw/core/cpu.h:877 + #2 0x00005555558ee776 in ich9_apm_ctrl_changed (val=32, arg=0x555556e2ff50) at hw/isa/lpc_ich9.c:442 + #3 0x0000555555b47f96 in apm_ioport_writeb (opaque=0x555556e308c0, addr=0, val=32, size=1) at hw/isa/apm.c:44 + #4 0x0000555555879931 in memory_region_write_accessor (mr=0x555556e308e0, addr=0, value=0x7fffffffb9f8, size=1, shift=0, mask=255, attrs=...) at memory.c:483 + #5 0x0000555555879b5a in access_with_adjusted_size (addr=0, value=0x7fffffffb9f8, size=4, access_size_min=1, access_size_max=1, access_fn= + 0x55555587984e <memory_region_write_accessor>, mr=0x555556e308e0, attrs=...) at memory.c:544 + #6 0x000055555587ca32 in memory_region_dispatch_write (mr=0x555556e308e0, addr=0, data=32, op=MO_32, attrs=...) at memory.c:1465 + #7 0x000055555581b7e9 in flatview_write_continue (fv=0x55555698a790, addr=178, attrs=..., ptr=0x7fffffffbb84, len=4, addr1=0, l=4, mr=0x555556e308e0) at exec.c:3198 + #8 0x000055555581b92e in flatview_write (fv=0x55555698a790, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3238 + #9 0x000055555581bc81 in address_space_write (as=0x555556441220 <address_space_io>, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3329 + #10 0x0000555555873f08 in cpu_outl (addr=178, val=32) at ioport.c:80 + #11 0x000055555598a26a in hmp_ioport_write (mon=0x5555567621b0, qdict=0x555557702600) at monitor/misc.c:937 + #12 0x0000555555c9c5a5 in handle_hmp_command (mon=0x5555567621b0, cmdline=0x55555676aae1 "/1 0xb2 0x20") at monitor/hmp.c:1082 + #13 0x0000555555c99e02 in monitor_command_cb (opaque=0x5555567621b0, cmdline=0x55555676aae0 "o/1 0xb2 0x20", readline_opaque=0x0) at monitor/hmp.c:47 + ^ + HMP command from monitor + +Reported-by: Alexander Bulekov <email address hidden> +Buglink: https://bugs.launchpad.net/qemu/+bug/1878645 +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: Bug 1878645 <email address hidden> + +RFC because I believe the correct fix is to NOT use current_cpu +out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU. +--- + cpus.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/cpus.c b/cpus.c +index 41d1c5099f..1f6f43d221 100644 +--- a/cpus.c ++++ b/cpus.c +@@ -2106,6 +2106,9 @@ void qemu_init_vcpu(CPUState *cpu) + { + MachineState *ms = MACHINE(qdev_get_machine()); + ++ if (!current_cpu) { ++ current_cpu = cpu; ++ } + cpu->nr_cores = ms->smp.cores; + cpu->nr_threads = ms->smp.threads; + cpu->stopped = true; +-- +2.21.3 + + + +On 200701 2021, Philippe Mathieu-Daudé wrote: +> We can run I/O access with the 'i' or 'o' HMP commands in the +> monitor. These commands are expected to run on a vCPU. The +> monitor is not a vCPU thread. To avoid crashing, initialize +> the 'current_cpu' variable with the first vCPU created. The +> command executed on the monitor will end using it. +> +> This fixes: +> +> $ cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio +> o/4 0xcf8 0x8400f841 +> o/4 0xcfc 0xaa215d6d +> o/4 0x6d30 0x2ef8ffbe +> o/1 0xb2 0x20 +> EOF +> Segmentation fault (core dumped) +> +> Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. +> 0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57 +> 57 old_mask = cpu->interrupt_request; +> (gdb) bt +> #0 0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57 +> #1 0x00005555558ed7d2 in cpu_interrupt (cpu=0x0, mask=64) at include/hw/core/cpu.h:877 +> #2 0x00005555558ee776 in ich9_apm_ctrl_changed (val=32, arg=0x555556e2ff50) at hw/isa/lpc_ich9.c:442 +> #3 0x0000555555b47f96 in apm_ioport_writeb (opaque=0x555556e308c0, addr=0, val=32, size=1) at hw/isa/apm.c:44 +> #4 0x0000555555879931 in memory_region_write_accessor (mr=0x555556e308e0, addr=0, value=0x7fffffffb9f8, size=1, shift=0, mask=255, attrs=...) at memory.c:483 +> #5 0x0000555555879b5a in access_with_adjusted_size (addr=0, value=0x7fffffffb9f8, size=4, access_size_min=1, access_size_max=1, access_fn= +> 0x55555587984e <memory_region_write_accessor>, mr=0x555556e308e0, attrs=...) at memory.c:544 +> #6 0x000055555587ca32 in memory_region_dispatch_write (mr=0x555556e308e0, addr=0, data=32, op=MO_32, attrs=...) at memory.c:1465 +> #7 0x000055555581b7e9 in flatview_write_continue (fv=0x55555698a790, addr=178, attrs=..., ptr=0x7fffffffbb84, len=4, addr1=0, l=4, mr=0x555556e308e0) at exec.c:3198 +> #8 0x000055555581b92e in flatview_write (fv=0x55555698a790, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3238 +> #9 0x000055555581bc81 in address_space_write (as=0x555556441220 <address_space_io>, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3329 +> #10 0x0000555555873f08 in cpu_outl (addr=178, val=32) at ioport.c:80 +> #11 0x000055555598a26a in hmp_ioport_write (mon=0x5555567621b0, qdict=0x555557702600) at monitor/misc.c:937 +> #12 0x0000555555c9c5a5 in handle_hmp_command (mon=0x5555567621b0, cmdline=0x55555676aae1 "/1 0xb2 0x20") at monitor/hmp.c:1082 +> #13 0x0000555555c99e02 in monitor_command_cb (opaque=0x5555567621b0, cmdline=0x55555676aae0 "o/1 0xb2 0x20", readline_opaque=0x0) at monitor/hmp.c:47 +> ^ +> HMP command from monitor +> +> Reported-by: Alexander Bulekov <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1878645 +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> Cc: Bug 1878645 <email address hidden> +> +> RFC because I believe the correct fix is to NOT use current_cpu +> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU. +> --- +> cpus.c | 3 +++ +> 1 file changed, 3 insertions(+) +> +> diff --git a/cpus.c b/cpus.c +> index 41d1c5099f..1f6f43d221 100644 +> --- a/cpus.c +> +++ b/cpus.c +> @@ -2106,6 +2106,9 @@ void qemu_init_vcpu(CPUState *cpu) +> { +> MachineState *ms = MACHINE(qdev_get_machine()); +> +> + if (!current_cpu) { +> + current_cpu = cpu; +> + } + +Seems like a neat solution. +is it fair to assume that qemu_init_vcpu is called before any threads +that can do I/O are created? I confirmed that the qtest and hmp crashes +are avoided. +-Alex + +> cpu->nr_cores = ms->smp.cores; +> cpu->nr_threads = ms->smp.threads; +> cpu->stopped = true; +> -- +> 2.21.3 +> + + +On Wed, 1 Jul 2020 at 19:21, Philippe Mathieu-Daudé <email address hidden> wrote: +> +> We can run I/O access with the 'i' or 'o' HMP commands in the +> monitor. These commands are expected to run on a vCPU. The +> monitor is not a vCPU thread. To avoid crashing, initialize +> the 'current_cpu' variable with the first vCPU created. The +> command executed on the monitor will end using it. + +> +> RFC because I believe the correct fix is to NOT use current_cpu +> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU. + +Yes, I agree -- I don't think this is the correct fix. +current_cpu is documented as "only valid inside cpu_exec()", +ie if you're actually on a vcpu thread you can use it, but if +you're not on a CPU thread, like the monitor, you need to +say which vCPU you want to affect. For the monitor, that +would be the current "default cpu" as set by the "cpu" +command (cf monitor_set_cpu()). The bug here will be that +somewhere along the line we are probably missing plumbing +sufficient to pass down "which CPU do we want". + +https://bugs.launchpad.net/qemu/+bug/1602247 is a bug of +a similar nature -- if the gdbstub does a memory access +we know which CPU we're trying to do that memory access as, +but it doesn't get plumbed through and so in the Arm GIC +register read/write function that looks at current_cpu +we get a segfault. + +One way to fix this would be to do something akin to how +real hardware works -- encode into the MemTxAttrs an +indication of what the transaction master was (eg the +CPU number for CPUs); then the handful of devices that +care about which CPU was doing the transaction can use +that, rather than directly looking at current_cpu, and +when gdbstub or monitor perform an access that should +act like it's from a particular CPU they can indicate +that by supplying appropriate transaction attributes. +That would potentially be quite a bit of work though +(but I think it would be a neat design if we want to +try to fix this kind of "segfault if the user prods +a device via the monitor" bug). + ++ if (!current_cpu) { ++ current_cpu = cpu; ++ } + +Some more specific issues with this -- current_cpu is +a thread-local variable, so this will set that for +whatever thread happens to make this call, which +might or might not be the one that ends up handling +the monitor command. Also some code assumes that +current_cpu is non-NULL only if this is a vCPU thread, +eg sigbus_handler(). + +thanks +-- PMM + + +On 7/1/20 10:35 PM, Peter Maydell wrote: +> On Wed, 1 Jul 2020 at 19:21, Philippe Mathieu-Daudé <email address hidden> wrote: +>> +>> We can run I/O access with the 'i' or 'o' HMP commands in the +>> monitor. These commands are expected to run on a vCPU. The +>> monitor is not a vCPU thread. To avoid crashing, initialize +>> the 'current_cpu' variable with the first vCPU created. The +>> command executed on the monitor will end using it. +> +>> +>> RFC because I believe the correct fix is to NOT use current_cpu +>> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU. +> +> Yes, I agree -- I don't think this is the correct fix. +> current_cpu is documented as "only valid inside cpu_exec()", +> ie if you're actually on a vcpu thread you can use it, but if +> you're not on a CPU thread, like the monitor, you need to +> say which vCPU you want to affect. For the monitor, that +> would be the current "default cpu" as set by the "cpu" +> command (cf monitor_set_cpu()). The bug here will be that +> somewhere along the line we are probably missing plumbing +> sufficient to pass down "which CPU do we want". + +TIL mon_get_cpu() :) + +This is a bit different here, the monitor is not doing an +access on a CPU address space, but directly on the I/O +address space. The APM port is registered by the ICH9 +south bridge, and this triggers a SMI exception on a +CPU core, but I have no idea which one, a random one? +Then this particular core will switch to SMM mode. + +Another way of seeing this problem, is imagining we +start a PIT timer from the monitor. When the timer +expires, the PIT will interrupt the CPU. Which CPU +to interrupt? We are not in the context of the monitor. + +> https://bugs.launchpad.net/qemu/+bug/1602247 is a bug of +> a similar nature -- if the gdbstub does a memory access +> we know which CPU we're trying to do that memory access as, +> but it doesn't get plumbed through and so in the Arm GIC +> register read/write function that looks at current_cpu +> we get a segfault. +> +> One way to fix this would be to do something akin to how +> real hardware works -- encode into the MemTxAttrs an +> indication of what the transaction master was (eg the +> CPU number for CPUs); then the handful of devices that +> care about which CPU was doing the transaction can use +> that, rather than directly looking at current_cpu, and +> when gdbstub or monitor perform an access that should +> act like it's from a particular CPU they can indicate +> that by supplying appropriate transaction attributes. +> That would potentially be quite a bit of work though +> (but I think it would be a neat design if we want to +> try to fix this kind of "segfault if the user prods +> a device via the monitor" bug). + +This is complex stuff. Too early for me to digest, I am +keeping this for later (I am not ignoring your comment). + +> +> + if (!current_cpu) { +> + current_cpu = cpu; +> + } +> +> Some more specific issues with this -- current_cpu is +> a thread-local variable, so this will set that for +> whatever thread happens to make this call, which +> might or might not be the one that ends up handling +> the monitor command. Also some code assumes that +> current_cpu is non-NULL only if this is a vCPU thread, +> eg sigbus_handler(). + +Yes, I agree. + +> +> thanks +> -- PMM +> + + + + +Paolo Bonzini <email address hidden> writes: + +> On 01/07/20 22:35, Peter Maydell wrote: +>> For the monitor, that +>> would be the current "default cpu" as set by the "cpu" +>> command (cf monitor_set_cpu()). The bug here will be that +>> somewhere along the line we are probably missing plumbing +>> sufficient to pass down "which CPU do we want". +> +> Yeah, the fix is probably to add a functions that returns either +> current_cpu or the monitor CPU, and use it in device emulation if +> applicable. +> +> The problem with current_cpu is that it affects stuff like run_on_cpu, +> and that is guaranteed to cause havoc to code that expects to run on a +> given CPU and therefore doesn't use locks. + +IIRC the original reported bug was in a APM callback which was triggered +by an MMIO operation. Currently we don't expose the current cpu via the +memory dispatch routines. Should we to ensure there is always something +valid there? + +> +> Paolo + + +-- +Alex Bennée + + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/536 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/105/KVM/1879646 b/results/classifier/105/KVM/1879646 new file mode 100644 index 00000000..9c8083b1 --- /dev/null +++ b/results/classifier/105/KVM/1879646 @@ -0,0 +1,52 @@ +KVM: 0.450 +device: 0.406 +socket: 0.337 +semantic: 0.331 +boot: 0.317 +graphic: 0.311 +network: 0.303 +mistranslation: 0.266 +other: 0.208 +assembly: 0.204 +instruction: 0.201 +vnc: 0.189 + +[Feature request] x86: dump MSR features in human form + +QEMU might fail because host/guest cpu features are not properly configured: + +qemu-system-x86_64: error: failed to set MSR 0x48f to 0x7fefff00036dfb +qemu-system-x86_64: /root/qemu-master/target/i386/kvm.c:2695: +kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +To ease debugging, it the MSR features bit could be dumped. + +Example in this thread: + +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05593.html + + The high 32 bits are 0111 1111 1110 1111 1111 1111. + + The low 32 bits are 0000 0011 0110 1101 1111 1011. + + The features that are set are the xor, so 0111 1100 1000 0010 0000 0100: + + - bit 2, vmx-exit-nosave-debugctl + - bit 9, host address space size, is handled automatically by QEMU + - bit 15, vmx-exit-ack-intr + - bit 17, vmx-exit-save-pat + - bit 18, vmx-exit-load-pat + - bit 19, vmx-exit-save-efer + - bit 20, vmx-exit-load-efer + - bit 21, vmx-exit-save-preemption-timer + +This output ^^^ is easier to digest. + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/237 + + diff --git a/results/classifier/105/KVM/1880355 b/results/classifier/105/KVM/1880355 new file mode 100644 index 00000000..bb37e818 --- /dev/null +++ b/results/classifier/105/KVM/1880355 @@ -0,0 +1,148 @@ +KVM: 0.651 +other: 0.633 +vnc: 0.627 +mistranslation: 0.618 +graphic: 0.595 +device: 0.566 +semantic: 0.565 +instruction: 0.556 +assembly: 0.548 +socket: 0.533 +boot: 0.530 +network: 0.515 + +Length restrictions for fw_cfg_dma_transfer? + +For me, this takes close to 3 minutes at 100% CPU: +echo "outl 0x518 0x9596ffff" | ./i386-softmmu/qemu-system-i386 -M q35 -m 32 -nographic -accel qtest -monitor none -serial none -qtest stdio + +#0 phys_page_find (d=0x606000035d80, addr=136728041144404) at /exec.c:338 +#1 address_space_lookup_region (d=0x606000035d80, addr=136728041144404, resolve_subpage=true) at /exec.c:363 +#2 address_space_translate_internal (d=0x606000035d80, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, resolve_subpage=true) at /exec.c:382 +#3 flatview_do_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen_out=0x7fff1fc0d090, page_mask_out=0x0, is_write=true, is_mmio=true, target_as=0x7fff1fc0ce10, attrs=...) + pment/qemu/exec.c:520 +#4 flatview_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, is_write=true, attrs=...) at /exec.c:586 +#5 flatview_write_continue (fv=0x606000035d20, addr=136728041144404, attrs=..., ptr=0x7fff1fc0d660, len=172, addr1=136728041144400, l=172, mr=0x557fd54e77e0 <io_mem_unassigned>) + pment/qemu/exec.c:3160 +#6 flatview_write (fv=0x606000035d20, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3177 +#7 address_space_write (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3271 +#8 dma_memory_set (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, c=0 '\000', len=1378422272) at /dma-helpers.c:31 +#9 fw_cfg_dma_transfer (s=0x61a000001e80) at /hw/nvram/fw_cfg.c:400 +#10 fw_cfg_dma_mem_write (opaque=0x61a000001e80, addr=4, value=4294940309, size=4) at /hw/nvram/fw_cfg.c:467 +#11 memory_region_write_accessor (mr=0x61a000002200, addr=4, value=0x7fff1fc0e3d0, size=4, shift=0, mask=4294967295, attrs=...) at /memory.c:483 +#12 access_with_adjusted_size (addr=4, value=0x7fff1fc0e3d0, size=4, access_size_min=1, access_size_max=8, access_fn=0x557fd2288c80 <memory_region_write_accessor>, mr=0x61a000002200, attrs=...) + pment/qemu/memory.c:539 +#13 memory_region_dispatch_write (mr=0x61a000002200, addr=4, data=4294940309, op=MO_32, attrs=...) at /memory.c:1476 +#14 flatview_write_continue (fv=0x606000035f00, addr=1304, attrs=..., ptr=0x7fff1fc0ec40, len=4, addr1=4, l=4, mr=0x61a000002200) at /exec.c:3137 +#15 flatview_write (fv=0x606000035f00, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3177 +#16 address_space_write (as=0x557fd54e7bc0 <address_space_io>, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3271 + + +It looks like fw_cfg_dma_transfer gets the address(136728041144064) and length(1378422272) for the read from the value provided as input 4294940309 (0xFFFF9695) which lands in pcbios. Should there be any limits on the length of guest-memory that fw_cfg should populate? +Found by libfuzzer + +On 5/24/20 6:12 AM, Alexander Bulekov wrote: +> Public bug reported: +> +> For me, this takes close to 3 minutes at 100% CPU: +> echo "outl 0x518 0x9596ffff" | ./i386-softmmu/qemu-system-i386 -M q35 -m 32 -nographic -accel qtest -monitor none -serial none -qtest stdio +> +> #0 phys_page_find (d=0x606000035d80, addr=136728041144404) at /exec.c:338 +> #1 address_space_lookup_region (d=0x606000035d80, addr=136728041144404, resolve_subpage=true) at /exec.c:363 +> #2 address_space_translate_internal (d=0x606000035d80, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, resolve_subpage=true) at /exec.c:382 +> #3 flatview_do_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen_out=0x7fff1fc0d090, page_mask_out=0x0, is_write=true, is_mmio=true, target_as=0x7fff1fc0ce10, attrs=...) +> pment/qemu/exec.c:520 +> #4 flatview_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, is_write=true, attrs=...) at /exec.c:586 +> #5 flatview_write_continue (fv=0x606000035d20, addr=136728041144404, attrs=..., ptr=0x7fff1fc0d660, len=172, addr1=136728041144400, l=172, mr=0x557fd54e77e0 <io_mem_unassigned>) +> pment/qemu/exec.c:3160 +> #6 flatview_write (fv=0x606000035d20, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3177 +> #7 address_space_write (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3271 +> #8 dma_memory_set (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, c=0 '\000', len=1378422272) at /dma-helpers.c:31 +> #9 fw_cfg_dma_transfer (s=0x61a000001e80) at /hw/nvram/fw_cfg.c:400 +> #10 fw_cfg_dma_mem_write (opaque=0x61a000001e80, addr=4, value=4294940309, size=4) at /hw/nvram/fw_cfg.c:467 +> #11 memory_region_write_accessor (mr=0x61a000002200, addr=4, value=0x7fff1fc0e3d0, size=4, shift=0, mask=4294967295, attrs=...) at /memory.c:483 +> #12 access_with_adjusted_size (addr=4, value=0x7fff1fc0e3d0, size=4, access_size_min=1, access_size_max=8, access_fn=0x557fd2288c80 <memory_region_write_accessor>, mr=0x61a000002200, attrs=...) +> pment/qemu/memory.c:539 +> #13 memory_region_dispatch_write (mr=0x61a000002200, addr=4, data=4294940309, op=MO_32, attrs=...) at /memory.c:1476 +> #14 flatview_write_continue (fv=0x606000035f00, addr=1304, attrs=..., ptr=0x7fff1fc0ec40, len=4, addr1=4, l=4, mr=0x61a000002200) at /exec.c:3137 +> #15 flatview_write (fv=0x606000035f00, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3177 +> #16 address_space_write (as=0x557fd54e7bc0 <address_space_io>, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3271 +> +> +> It looks like fw_cfg_dma_transfer gets the address(136728041144064) and length(1378422272) for the read from the value provided as input 4294940309 (0xFFFF9695) which lands in pcbios. Should there be any limits on the length of guest-memory that fw_cfg should populate? + +It looks to me a normal behavior for a DMA device. DMA devices have a +different address space view than the CPUs. +Also note the fw_cfg is a generic device, not restricted to the x86 arch. + +Maybe this function could use dma_memory_valid() to skip unassigned regions? + + + +On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé <email address hidden> wrote: +> It looks to me a normal behavior for a DMA device. DMA devices have a +> different address space view than the CPUs. +> Also note the fw_cfg is a generic device, not restricted to the x86 arch. + +In an ideal world all our DMA devices would use some kind of common +framework or design pattern so they didn't hog all the CPU +and/or spend minutes with the BQL held if the guest requests +an enormous-sized DMA. In practice many of them just have +a simple "loop until the DMA transfer is complete" implementation... + +thanks +-- PMM + + +On 5/24/20 3:40 PM, Peter Maydell wrote: +> On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé <email address hidden> wrote: +>> It looks to me a normal behavior for a DMA device. DMA devices have a +>> different address space view than the CPUs. +>> Also note the fw_cfg is a generic device, not restricted to the x86 arch. +> +> In an ideal world all our DMA devices would use some kind of common +> framework or design pattern so they didn't hog all the CPU +> and/or spend minutes with the BQL held if the guest requests +> an enormous-sized DMA. In practice many of them just have +> a simple "loop until the DMA transfer is complete" implementation... + +Is this framework already implemented in the hidden dma-helpers.c? + +Apparently this file was written for BlockBackend, but the code seems +rather generic. + + + +On 24/05/2020 14:40, Peter Maydell wrote: + +> On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé <email address hidden> wrote: +>> It looks to me a normal behavior for a DMA device. DMA devices have a +>> different address space view than the CPUs. +>> Also note the fw_cfg is a generic device, not restricted to the x86 arch. +> +> In an ideal world all our DMA devices would use some kind of common +> framework or design pattern so they didn't hog all the CPU +> and/or spend minutes with the BQL held if the guest requests +> an enormous-sized DMA. In practice many of them just have +> a simple "loop until the DMA transfer is complete" implementation... + +One of the problems with the PPC Mac DBDMA emulation is that the controller is +effectively a mini-CPU that runs its own programs for transferring data to/from memory. + +Currently this is done as a QEMU BH which means for larger transfers the emulated CPU +can be paused for a not insignificant amount of time until the program performing the +transfer finishes. I've always wondered if this should be running in a separate +thread to reduce its impact. + + +ATB, + +Mark. + + +Can you still reproduce this problem with the current git version of QEMU? ... for me, the command now returns immediately. + +This no longer causes timeout/excessive CPU usage for me. Probably fixed + +Ok, thanks for checking! Closing now. + diff --git a/results/classifier/105/KVM/1880507 b/results/classifier/105/KVM/1880507 new file mode 100644 index 00000000..f0ca711c --- /dev/null +++ b/results/classifier/105/KVM/1880507 @@ -0,0 +1,25 @@ +KVM: 0.983 +mistranslation: 0.971 +semantic: 0.860 +device: 0.799 +other: 0.704 +graphic: 0.655 +instruction: 0.469 +boot: 0.402 +network: 0.395 +socket: 0.230 +vnc: 0.109 +assembly: 0.082 + +VMM from Ubuntu 20.04 does not show the memory consumption + +KVM host system: Ubuntu 18.04 and 20.04, guest machines: Windows and Ubuntu. Management through Ubuntu 20.04, vmm does not show RAM consumption for Windows guest systems (Win7, Win2008R2), for Ubuntu values are shown. The error is not observed in Ubuntu 18.04/vmm. + +Does "vmm" mean Virtual Machine Manager (aka virt-manager)? If yes, +please file this bug against the virt-manager package instead of qemu. + +Thanks! + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/1883732 b/results/classifier/105/KVM/1883732 new file mode 100644 index 00000000..5432f960 --- /dev/null +++ b/results/classifier/105/KVM/1883732 @@ -0,0 +1,134 @@ +KVM: 0.941 +other: 0.905 +vnc: 0.845 +device: 0.812 +instruction: 0.775 +graphic: 0.751 +boot: 0.739 +mistranslation: 0.730 +network: 0.726 +socket: 0.712 +semantic: 0.667 +assembly: 0.609 + +xhci_kick_epctx: Assertion `ring->dequeue != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +Here's a QTest reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device nec-usb-xhci -trace usb\* \ +-device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001014 +outl 0xcfc 0xff000a8e +outl 0xcf8 0x80001004 +outl 0xcfc 0x1c77695e +writel 0xff000a8e00000040 0x1d00d815 +write 0x1d 0x1 0x5c +write 0x2d 0x1 0x27 +write 0x3d 0x1 0x2e +write 0xd 0x1 0x60 +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x05 +write 0x4d 0x1 0x5c +write 0x5d 0x1 0x27 +write 0x60 0x1 0x2e +write 0x61 0x1 0x72 +write 0x62 0x1 0x01 +write 0x6d 0x1 0x2e +write 0x6f 0x1 0x01 +writel 0xff000a8e00002000 0x0 +writeq 0xff000a8e00002000 0x514ef0100000009 +EOF + +The trace: +[R +0.031152] writel 0xff000a8e00000040 0x1d00d815 +26994@1597124755.565242:usb_xhci_oper_write off 0x0000, val 0x1d00d815 +26994@1597124755.565247:usb_xhci_run +26994@1597124755.565252:usb_xhci_irq_intx level 0 +OK +[S +0.031173] OK +[R +0.031179] write 0x1d 0x1 0x5c +OK +[S +0.031190] OK +[R +0.031195] write 0x2d 0x1 0x27 +OK +[S +0.031198] OK +[R +0.031203] write 0x3d 0x1 0x2e +OK +[S +0.031207] OK +[R +0.031211] write 0xd 0x1 0x60 +OK +[S +0.031214] OK +[R +0.031219] write 0x17232 0x1 0x03 +OK +[S +0.031224] OK +[R +0.031228] write 0x17254 0x1 0x05 +OK +[S +0.031231] OK +[R +0.031236] write 0x4d 0x1 0x5c +OK +[S +0.031239] OK +[R +0.031244] write 0x5d 0x1 0x27 +OK +[S +0.031247] OK +[R +0.031251] write 0x60 0x1 0x2e +OK +[S +0.031254] OK +[R +0.031259] write 0x61 0x1 0x72 +OK +[S +0.031262] OK +[R +0.031267] write 0x62 0x1 0x01 +OK +[S +0.031270] OK +[R +0.031275] write 0x6d 0x1 0x2e +OK +[S +0.031278] OK +[R +0.031282] write 0x6f 0x1 0x01 +OK +[S +0.031286] OK +[R +0.031290] writel 0xff000a8e00002000 0x0 +26994@1597124755.565377:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +26994@1597124755.565384:usb_xhci_fetch_trb addr 0x0000000000000000, ???, p 0x0000000000000000, s 0x00000000, c 0x00006000 +26994@1597124755.565390:usb_xhci_unimplemented command (0x18) +26994@1597124755.565395:usb_xhci_fetch_trb addr 0x0000000000000010, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00 +26994@1597124755.565399:usb_xhci_fetch_trb addr 0x0000000000000020, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +26994@1597124755.565403:usb_xhci_slot_enable slotid 1 +26994@1597124755.565406:usb_xhci_fetch_trb addr 0x0000000000000030, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +26994@1597124755.565411:usb_xhci_fetch_trb addr 0x0000000000000040, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00 +26994@1597124755.565416:usb_xhci_fetch_trb addr 0x0000000000000050, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +26994@1597124755.565421:usb_xhci_slot_enable slotid 2 +26994@1597124755.565423:usb_xhci_fetch_trb addr 0x0000000000000060, CR_ADDRESS_DEVICE, p 0x000000000001722e, s 0x00000000, c 0x01002e00 +26994@1597124755.565431:usb_xhci_slot_address slotid 1, port 1 +26994@1597124755.565436:usb_xhci_ep_enable slotid 1, epid 1 +26994@1597124755.565444:usb_xhci_fetch_trb addr 0x0000000000000070, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +OK +[S +0.031365] OK +[R +0.031370] writeq 0xff000a8e00002000 0x514ef0100000009 +26994@1597124755.565456:usb_xhci_doorbell_write off 0x0000, val 0x00000009 +26994@1597124755.565459:usb_xhci_doorbell_write off 0x0004, val 0x0514ef01 +26994@1597124755.565462:usb_xhci_ep_kick slotid 1, epid 1, streamid 1300 +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/hw/usb/hcd-xhci.c:1955: void xhci_kick_epctx(XHCIEPContext *, unsigned int): Assertion `ring->dequeue != 0' failed. +Aborted + +-Alex + +ClusterFuzz testcase 5662083651469312 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_qemu&range=202011160601:202011170627 + diff --git a/results/classifier/105/KVM/1883733 b/results/classifier/105/KVM/1883733 new file mode 100644 index 00000000..dd1c8a9c --- /dev/null +++ b/results/classifier/105/KVM/1883733 @@ -0,0 +1,370 @@ +mistranslation: 0.945 +KVM: 0.928 +other: 0.914 +vnc: 0.901 +instruction: 0.884 +assembly: 0.866 +semantic: 0.832 +device: 0.814 +graphic: 0.811 +boot: 0.785 +network: 0.779 +socket: 0.756 + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +OSS-Fuzz reported this: + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none \ +-machine accel=qtest, -m 512M -machine q35 -nodefaults \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-tablet -device usb-wacom-tablet -device usb-audio \ +-qtest stdio +outl 0xcf8 0x80000803 +outl 0xcfc 0x18ffffff +outl 0xcf8 0x80000813 +outb 0xcfc 0x5e +write 0x5e000074 0x4 0x5a636c6f +writel 0x5e000040 0x5adeb005 +write 0xd 0x1 0x24 +write 0x1d 0x1 0x2e +write 0x2d 0x1 0xff +write 0x3d 0x1 0x24 +write 0x4d 0x1 0x2e +write 0x5d 0x1 0xff +write 0x6d 0x1 0x24 +write 0x7d 0x1 0x2e +write 0x8d 0x1 0xff +write 0x9d 0x1 0x24 +write 0xad 0x1 0x2e +write 0xbd 0x1 0xff +write 0xcd 0x1 0x24 +write 0xdd 0x1 0x2e +write 0x6d04 0x1 0x03 +write 0x6d26 0x1 0x04 +write 0xed 0x1 0xff +write 0xfd 0x1 0x24 +write 0x10d 0x1 0x2e +write 0x11d 0x1 0xff +write 0x12d 0x1 0x24 +write 0x13d 0x1 0x2e +write 0x14d 0x1 0xff +write 0x15d 0x1 0x24 +write 0x16d 0x1 0x2e +write 0x17d 0x1 0xff +write 0x18d 0x1 0x24 +write 0x19d 0x1 0x2e +write 0x1ad 0x1 0xff +write 0x1bd 0x1 0x24 +write 0x1cd 0x1 0x2e +write 0x1dd 0x1 0xff +write 0x1ed 0x1 0x24 +write 0x1fd 0x1 0x2e +write 0x20d 0x1 0xff +write 0x21d 0x1 0x24 +write 0x22d 0x1 0x2e +write 0x23d 0x1 0xff +write 0x24d 0x1 0x24 +write 0x25d 0x1 0x2e +write 0x26d 0x1 0xff +write 0x27d 0x1 0x24 +write 0x28d 0x1 0x2e +write 0x29d 0x1 0xff +write 0x2ad 0x1 0x24 +write 0x2bd 0x1 0x2e +write 0x2cd 0x1 0xff +write 0x2dd 0x1 0x24 +write 0x2ed 0x1 0x2e +write 0x2fd 0x1 0xff +write 0x30d 0x1 0x24 +write 0x31d 0x1 0x2e +write 0x32d 0x1 0xff +write 0x33d 0x1 0x24 +write 0x34d 0x1 0x2e +write 0x35d 0x1 0xff +write 0x36d 0x1 0x24 +write 0x37d 0x1 0x2e +write 0x38d 0x1 0xff +write 0x39d 0x1 0x24 +write 0x3ad 0x1 0x2e +write 0x3bd 0x1 0xff +write 0x3cd 0x1 0x24 +write 0x3dd 0x1 0x2e +write 0x3ed 0x1 0xff +write 0x3fd 0x1 0x24 +write 0x40d 0x1 0x2e +write 0x41d 0x1 0xff +write 0x42d 0x1 0x24 +write 0x43d 0x1 0x2e +write 0x44d 0x1 0xff +write 0x45d 0x1 0x24 +write 0x46d 0x1 0x2e +write 0x47d 0x1 0xff +write 0x48d 0x1 0x24 +write 0x49d 0x1 0x2e +write 0x4ad 0x1 0xff +write 0x4bd 0x1 0x24 +write 0x4cd 0x1 0x2e +write 0x4dd 0x1 0xff +write 0x4ed 0x1 0x24 +write 0x4fd 0x1 0x2e +write 0x50d 0x1 0xff +write 0x51d 0x1 0x24 +write 0x52d 0x1 0x2e +write 0x53d 0x1 0xff +write 0x54d 0x1 0x24 +write 0x55d 0x1 0x2e +write 0x56d 0x1 0xff +write 0x57d 0x1 0x24 +write 0x58d 0x1 0x2e +write 0x59d 0x1 0xff +write 0x5ad 0x1 0x24 +write 0x5bd 0x1 0x2e +write 0x5cd 0x1 0xff +write 0x5dd 0x1 0x24 +write 0x5ed 0x1 0x2e +write 0x5fd 0x1 0xff +write 0x60d 0x1 0x24 +write 0x61d 0x1 0x2e +write 0x62d 0x1 0xff +write 0x63d 0x1 0x24 +write 0x64d 0x1 0x2e +write 0x65d 0x1 0xff +write 0x66d 0x1 0x24 +write 0x67d 0x1 0x2e +write 0x68d 0x1 0xff +write 0x69d 0x1 0x24 +write 0x6ad 0x1 0x2e +write 0x6bd 0x1 0xff +write 0x6cd 0x1 0x24 +write 0x6dd 0x1 0x2e +write 0x6ed 0x1 0xff +write 0x6fd 0x1 0x24 +write 0x70d 0x1 0x2e +write 0x71d 0x1 0xff +write 0x72d 0x1 0x24 +write 0x73d 0x1 0x2e +write 0x74d 0x1 0xff +write 0x75d 0x1 0x24 +write 0x76d 0x1 0x2e +write 0x77d 0x1 0xff +write 0x78d 0x1 0x24 +write 0x79d 0x1 0x2e +write 0x7ad 0x1 0xff +write 0x7bd 0x1 0x24 +write 0x7cd 0x1 0x2e +write 0x7dd 0x1 0xff +write 0x7ed 0x1 0x24 +write 0x7fd 0x1 0x2e +write 0x80d 0x1 0xff +write 0x81d 0x1 0x24 +write 0x82d 0x1 0x2e +write 0x83d 0x1 0xff +write 0x84d 0x1 0x24 +write 0x85d 0x1 0x2e +write 0x86d 0x1 0xff +write 0x87d 0x1 0x24 +write 0x88d 0x1 0x2e +write 0x89d 0x1 0xff +write 0x8ad 0x1 0x24 +write 0x8bd 0x1 0x2e +write 0x8cd 0x1 0xff +write 0x8dd 0x1 0x24 +write 0x8ed 0x1 0x2e +write 0x8fd 0x1 0xff +write 0x90d 0x1 0x24 +write 0x91d 0x1 0x2e +write 0x92d 0x1 0xff +write 0x93d 0x1 0x24 +write 0x94d 0x1 0x2e +write 0x95d 0x1 0xff +write 0x96d 0x1 0x24 +write 0x97d 0x1 0x2e +write 0x98d 0x1 0xff +write 0x99d 0x1 0x24 +write 0x9ad 0x1 0x2e +write 0x9bd 0x1 0xff +write 0x9cd 0x1 0x24 +write 0x9dd 0x1 0x2e +write 0x9ed 0x1 0xff +write 0x9fd 0x1 0x24 +write 0xa0d 0x1 0x2e +write 0xa1d 0x1 0xff +write 0xa2d 0x1 0x24 +write 0xa3d 0x1 0x2e +write 0xa4d 0x1 0xff +write 0xa5d 0x1 0x24 +write 0xa6d 0x1 0x2e +write 0xa7d 0x1 0xff +write 0xa8d 0x1 0x24 +write 0xa9d 0x1 0x2e +write 0xaad 0x1 0xff +write 0xabd 0x1 0x24 +write 0xacd 0x1 0x2e +write 0xadd 0x1 0xff +write 0xaed 0x1 0x24 +write 0xafd 0x1 0x2e +write 0xb0d 0x1 0xff +write 0xb1d 0x1 0x24 +write 0xb2d 0x1 0x2e +write 0xb3d 0x1 0xff +write 0xb4d 0x1 0x24 +write 0xb5d 0x1 0x2e +write 0xb6d 0x1 0xff +write 0xb7d 0x1 0x24 +write 0xb8d 0x1 0x2e +write 0xb9d 0x1 0xff +write 0xbad 0x1 0x24 +write 0xbbd 0x1 0x2e +write 0xbcd 0x1 0xff +write 0xbdd 0x1 0x24 +write 0xbed 0x1 0x2e +write 0xbfd 0x1 0xff +write 0xc0d 0x1 0x24 +write 0xc1d 0x1 0x2e +write 0xc2d 0x1 0xff +write 0xc3d 0x1 0x24 +write 0xc4d 0x1 0x2e +write 0xc5d 0x1 0xff +write 0xc6d 0x1 0x24 +write 0xc7d 0x1 0x2e +write 0xc8d 0x1 0xff +write 0xc9d 0x1 0x24 +write 0xcad 0x1 0x2e +write 0xcbd 0x1 0xff +write 0xccd 0x1 0x24 +write 0xcdd 0x1 0x2e +write 0xced 0x1 0xff +write 0xcfd 0x1 0x24 +write 0xd0d 0x1 0x2e +write 0xd1d 0x1 0xff +write 0xd2d 0x1 0x24 +write 0xd3d 0x1 0x2e +write 0xd4d 0x1 0xff +write 0xd5d 0x1 0x24 +write 0xd6d 0x1 0x2e +write 0xd7d 0x1 0xff +write 0xd8d 0x1 0x24 +write 0xd9d 0x1 0x2e +write 0xdad 0x1 0xff +write 0xdbd 0x1 0x24 +write 0xdcd 0x1 0x2e +write 0xddd 0x1 0xff +write 0xded 0x1 0x24 +write 0xdfd 0x1 0x2e +write 0xe0d 0x1 0xff +write 0xe1d 0x1 0x24 +write 0xe2d 0x1 0x2e +write 0xe3d 0x1 0xff +write 0xe4d 0x1 0x24 +write 0xe5d 0x1 0x2e +write 0xe6d 0x1 0xff +write 0xe7d 0x1 0x24 +write 0xe8d 0x1 0x2e +write 0xe9d 0x1 0xff +write 0xead 0x1 0x24 +write 0xebd 0x1 0x2e +write 0xecd 0x1 0xff +write 0xedd 0x1 0x24 +write 0xeed 0x1 0x2e +write 0xefd 0x1 0xff +write 0xf0d 0x1 0x24 +write 0xf1d 0x1 0x2e +write 0xf2d 0x1 0xff +write 0xf3d 0x1 0x24 +write 0xf4d 0x1 0x2e +write 0xf5d 0x1 0xff +write 0xf6d 0x1 0x24 +write 0xf7d 0x1 0x2e +write 0xf8d 0x1 0xff +write 0xf9d 0x1 0x24 +write 0xfad 0x1 0x2e +write 0xfbd 0x1 0xff +write 0xfcd 0x1 0x24 +write 0xfdd 0x1 0x2e +write 0xfed 0x1 0xff +write 0xffd 0x1 0x24 +write 0x1001 0x1 0x6d +write 0x100d 0x1 0x2e +write 0x100f 0x1 0x05 +writel 0x5e002000 0x0 +write 0x102d 0x1 0x24 +write 0x103d 0x1 0x2e +write 0x1040 0x1 0xfe +write 0x1041 0x1 0xff +write 0x1042 0x1 0xff +write 0x1043 0x1 0xff +write 0x1044 0x1 0xff +write 0x1045 0x1 0xff +write 0x1046 0x1 0xff +write 0x1047 0x1 0xff +write 0x104d 0x1 0x31 +write 0x104f 0x1 0x05 +write 0x2 0x1 0x11 +write 0x3 0x1 0x07 +write 0xf 0x1 0x73 +write 0x9f 0x1 0x65 +write 0x13f 0x1 0x6d +writel 0x5e002000 0x0 +EOF + +=== Stack Trace === +FIXME xhci_alloc_device_streams:921 guest streams config not identical for all eps +==683875== ERROR: libFuzzer: deadly signal +0x56009f09d311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311) +0x56009efe63d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8) +0x56009efcc413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413) +0x7f0aed93e13f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f) +0x7f0aed773db0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 +0x7f0aed773db0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +0x7f0aed75d536 in abort stdlib/abort.c:79:7 +0x56009f4ecde7 in xhci_alloc_device_streams hw/usb/hcd-xhci.c:921:13 +0x56009f4ecde7 in xhci_configure_slot hw/usb/hcd-xhci.c:2223:11 +0x56009f4ecde7 in xhci_process_commands hw/usb/hcd-xhci.c:2466:31 +0x56009f4e36fb in xhci_doorbell_write hw/usb/hcd-xhci.c:3100:13 +0x5600a07fb025 in memory_region_write_accessor softmmu/memory.c:491:5 +0x5600a07faa93 in access_with_adjusted_size softmmu/memory.c:552:18 +0x5600a07fa2f0 in memory_region_dispatch_write softmmu/memory.c +0x5600a0249f36 in flatview_write_continue softmmu/physmem.c:2759:23 +0x5600a023fbbb in flatview_write softmmu/physmem.c:2799:14 +0x5600a023fbbb in address_space_write softmmu/physmem.c:2891:18 +0x5600a06d4362 in qtest_process_command softmmu/qtest.c:534:13 +0x5600a06d15bf in qtest_process_inbuf softmmu/qtest.c:797:9 +0x5600a06d1315 in qtest_server_inproc_recv softmmu/qtest.c:904:9 +0x5600a0d0edf8 in qtest_sendf tests/qtest/libqtest.c:438:5 +0x5600a0d1038e in qtest_write tests/qtest/libqtest.c:1004:5 +0x5600a0d1038e in qtest_writel tests/qtest/libqtest.c:1020:5 +0x56009f0d7eaa in __wrap_qtest_writel tests/qtest/fuzz/qtest_wrappers.c:180:9 +0x56009f0d0299 in op_write tests/qtest/fuzz/generic_fuzz.c:473:13 +0x56009f0ce4e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17 +0x56009f0c7723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5 + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28602 + + + + +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/274 + + diff --git a/results/classifier/105/KVM/1888601 b/results/classifier/105/KVM/1888601 new file mode 100644 index 00000000..07bc18d7 --- /dev/null +++ b/results/classifier/105/KVM/1888601 @@ -0,0 +1,329 @@ +KVM: 0.530 +mistranslation: 0.514 +other: 0.485 +device: 0.455 +instruction: 0.453 +vnc: 0.452 +socket: 0.451 +assembly: 0.443 +graphic: 0.435 +network: 0.431 +boot: 0.404 +semantic: 0.400 + +QEMU v5.1.0-rc0/rc1 hang with nested virtualization + +We're running Kata Containers using QEMU and with v5.1.0rc0 and rc1 have noticed a problem at startup where QEMu appears to hang. We are not seeing this problem on our bare metal nodes and only on a VSI that supports nested virtualization. + +We unfortunately see nothing at all in the QEMU logs to help understand the problem and a hung process is just a guess at this point. + +Using git bisect we first see the problem with... + +--- + +f19bcdfedd53ee93412d535a842a89fa27cae7f2 is the first bad commit +commit f19bcdfedd53ee93412d535a842a89fa27cae7f2 +Author: Jason Wang <email address hidden> +Date: Wed Jul 1 22:55:28 2020 +0800 + + virtio-pci: implement queue_enabled method + + With version 1, we can detect whether a queue is enabled via + queue_enabled. + + Signed-off-by: Jason Wang <email address hidden> + Signed-off-by: Cindy Lu <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + Acked-by: Jason Wang <email address hidden> + + hw/virtio/virtio-pci.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- + +Reverting this commit seems to work and prevent the hanging. + +--- + +Here's how kata ends up launching qemu in our environment -- +/opt/kata/bin/qemu-system-x86_64 -name sandbox-849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f -uuid 6bec458e-1da7-4847-a5d7-5ab31d4d2465 -machine pc,accel=kvm,kernel_irqchip -cpu host,pmu=off -qmp unix:/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/qmp.sock,server,nowait -m 4096M,slots=10,maxmem=30978M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= -device virtio-serial-pci,disable-modern=true,id=serial0,romfile= -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/console.sock,server,nowait -device virtio-scsi-pci,id=scsi0,disable-modern=true,romfile= -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0,romfile= -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 -chardev socket,id=charch0,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/kata.sock,server,nowait -chardev socket,id=char-396c5c3e19e29353,path=/run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/vhost-fs.sock -device vhost-user-fs-pci,chardev=char-396c5c3e19e29353,tag=kataShared,romfile= -netdev tap,id=network-0,vhost=on,vhostfds=3:4,fds=5:6 -device driver=virtio-net-pci,netdev=network-0,mac=52:ac:2d:02:1f:6f,disable-modern=true,mq=on,vectors=6,romfile= -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -object memory-backend-file,id=dimm1,size=4096M,mem-path=/dev/shm,share=on -numa node,memdev=dimm1 -kernel /opt/kata/share/kata-containers/vmlinuz-5.7.9-74 -initrd /opt/kata/share/kata-containers/kata-containers-initrd_alpine_1.11.2-6_agent.initrd -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=4 agent.use_vsock=false scsi_mod.scan=none init=/usr/bin/kata-agent -pidfile /run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/pid -D /run/vc/vm/849df14c6065931adedb9d18bc9260a6d896f1814a8c5cfa239865772f1b7a5f/qemu.log -smp 2,cores=1,threads=1,sockets=4,maxcpus=4 + +--- + +Seems an odd one to be the culprit? Still lets ask Jason. +Can you just clarify; is this qemu 5.1.0-rc on both the host and the kata, or are you just changing to using qemu 5.1 as the host, and you're sticking with the existing kata qemu? + +Which host CPU have you got? + +I believe the VSI itself is QEMU based but don't know the version or details but suspect it's 4.1 based. We compile our own QEMU version for use with Kata and that's where we're now using 5.1.0-rc1 with the above commit reverted. + +Host Kernel is ... 4.15.0-101-generic if that helps + +re: cpu -- four of these... +``` +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 61 +model name : Intel Core Processor (Broadwell, IBRS) +stepping : 2 +microcode : 0x1 +cpu MHz : 2095.148 +cache size : 16384 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat md_clear +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit +bogomips : 4190.29 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: +``` + + +Hi: + +It's not clear to me: + +- Is the hang happen on the host or L1 guest? +- Is qemu 5.1-rc0 used on the host or L1 guest? +- When did you see the hung, just after launching the guest? +- Can you use gdb to get a calltrace of qemu when you see the hang? +- What's the version of kernel in L1 and L2 guest? + +Thanks + +Simon: Please answer Jason's questions + +But my reading is; I don't know what a VSI is but I'm guessing it's the host and he doesn't know the host qemu; so the 5.1is the qemu that kata is running? + +It perhaps would make more sense if this has nothing to do with nesting, and more to do with Kata's virtio setup; I've just tried virtio-fs on current head (outside kata) and it seems OK from a quick test. + +:) Sorry a VSI is a virtual server instance e.g a VM vs. a bare metal server. + +I'm using IBM Cloud IKS which is a managed Kubernetes Service. I'm installing QEMU 5.1.x on the worker nodes. It is this instance of QEMU -- e.g. /opt/kata/bin/qemu-system-x86_64 -- that is hanging. The Kernel version at this level is... 4.15.0-101-generic. I don't know the QEMU or kernel version in the L0 host. + +FWIW the exact same setup with the identical OS, Kernel version, Kata runtime, QEMU etc. is working on a bare metal host. + + + +It hangs (still guessing here) immediately -- before anything is logged. I'll try to get you a calltrace but have to figure out how to do that first ;) Any pointers appreciated. + +Yon can get the calltrace by: + +1) compile the qemu with --enable-debug +2) using gdb -p $pid_of_qemu when you see the hang +3) thread apply all bt + +Thanks + +Thanks Jason, +Ok will do... gimme a day and I'll post what I see. + + +``` +(gdb) thread apply all bt + +Thread 5 (LWP 211759): +#0 0x00007ff56a9988d8 in g_str_hash () +#1 0x00007ff56a997a0c in g_hash_table_lookup () +#2 0x00007ff56a6c528f in type_table_lookup (name=0x7ff56ac9a9dd "virtio-bus") at qom/object.c:84 +#3 type_get_by_name (name=0x7ff56ac9a9dd "virtio-bus") at qom/object.c:171 +#4 object_class_dynamic_cast (class=class@entry=0x555556d92ac0, typename=typename@entry=0x7ff56ac9a9dd "virtio-bus") at qom/object.c:879 +#5 0x00007ff56a6c55b5 in object_class_dynamic_cast_assert (class=0x555556d92ac0, typename=typename@entry=0x7ff56ac9a9dd "virtio-bus", file=file@entry=0x7ff56aca60b8 "/root/qemu/hw/virtio/virtio.c", line=line@entry=3290, + func=func@entry=0x7ff56aca6c30 <__func__.31954> "virtio_queue_enabled") at qom/object.c:935 +#6 0x00007ff56a415842 in virtio_queue_enabled (vdev=0x555557ed9be0, n=0) at /root/qemu/hw/virtio/virtio.c:3290 +#7 0x00007ff56a5c0837 in vhost_net_start_one (dev=0x555557ed9be0, net=0x555556f99ca0) at hw/net/vhost_net.c:259 +#8 vhost_net_start (dev=dev@entry=0x555557ed9be0, ncs=0x555557eef030, total_queues=total_queues@entry=2) at hw/net/vhost_net.c:351 +#9 0x00007ff56a3f2d98 in virtio_net_vhost_status (status=<optimized out>, n=0x555557ed9be0) at /root/qemu/hw/net/virtio-net.c:268 +#10 virtio_net_set_status (vdev=0x555557ed9be0, status=<optimized out>) at /root/qemu/hw/net/virtio-net.c:349 +#11 0x00007ff56a413bdb in virtio_set_status (vdev=vdev@entry=0x555557ed9be0, val=val@entry=7 '\a') at /root/qemu/hw/virtio/virtio.c:1956 +#12 0x00007ff56a65bdf0 in virtio_ioport_write (val=7, addr=18, opaque=0x555557ed1a50) at hw/virtio/virtio-pci.c:331 +#13 virtio_pci_config_write (opaque=0x555557ed1a50, addr=18, val=<optimized out>, size=<optimized out>) at hw/virtio/virtio-pci.c:455 +#14 0x00007ff56a46eb2a in memory_region_write_accessor (attrs=..., mask=255, shift=<optimized out>, size=1, value=0x7ff463ffd5f8, addr=<optimized out>, mr=0x555557ed2340) at /root/qemu/softmmu/memory.c:483 +#15 access_with_adjusted_size (attrs=..., mr=0x555557ed2340, access_fn=<optimized out>, access_size_max=<optimized out>, access_size_min=<optimized out>, size=1, value=0x7ff463ffd5f8, addr=18) + at /root/qemu/softmmu/memory.c:544 +#16 memory_region_dispatch_write (mr=mr@entry=0x555557ed2340, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=..., attrs@entry=...) at /root/qemu/softmmu/memory.c:1465 +#17 0x00007ff56a3a94b2 in flatview_write_continue (fv=0x7ff45426a7c0, addr=addr@entry=53394, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7ff5687eb000, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, + mr=0x555557ed2340) at /root/qemu/include/qemu/host-utils.h:164 +#18 0x00007ff56a3adc4d in flatview_write (len=1, buf=0x7ff5687eb000, attrs=..., addr=53394, fv=<optimized out>) at /root/qemu/exec.c:3216 +#19 address_space_write (len=1, buf=0x7ff5687eb000, attrs=..., addr=53394, as=0x7ff5687eb000) at /root/qemu/exec.c:3307 +#20 address_space_rw (as=as@entry=0x7ff56b444d60 <address_space_io>, addr=addr@entry=53394, attrs=attrs@entry=..., buf=0x7ff5687eb000, len=len@entry=1, is_write=is_write@entry=true) at /root/qemu/exec.c:3317 +#21 0x00007ff56a3cdd5f in kvm_handle_io (count=1, size=1, direction=<optimized out>, data=<optimized out>, attrs=..., port=53394) at /root/qemu/accel/kvm/kvm-all.c:2262 +#22 kvm_cpu_exec (cpu=cpu@entry=0x555556ffaea0) at /root/qemu/accel/kvm/kvm-all.c:2508 +#23 0x00007ff56a46503c in qemu_kvm_cpu_thread_fn (arg=0x555556ffaea0) at /root/qemu/softmmu/cpus.c:1188 +#24 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556ffaea0) at /root/qemu/softmmu/cpus.c:1160 +#25 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#26 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#27 0x00007ff56ac43353 in clone () + +Thread 4 (LWP 211758): +#0 0x00007ff56ac3eebb in ioctl () +#1 0x00007ff56a3cd98b in kvm_vcpu_ioctl (cpu=cpu@entry=0x555556fb4ac0, type=type@entry=44672) at /root/qemu/accel/kvm/kvm-all.c:2631 +#2 0x00007ff56a3cdac5 in kvm_cpu_exec (cpu=cpu@entry=0x555556fb4ac0) at /root/qemu/accel/kvm/kvm-all.c:2468 +#3 0x00007ff56a46503c in qemu_kvm_cpu_thread_fn (arg=0x555556fb4ac0) at /root/qemu/softmmu/cpus.c:1188 +#4 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556fb4ac0) at /root/qemu/softmmu/cpus.c:1160 +#5 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007ff56ac43353 in clone () + +Thread 3 (LWP 211757): +#0 0x00007ff56ac3dd0f in poll () +#1 0x00007ff56a9aa5de in g_main_context_iterate.isra () at pthread_create.c:679 +#2 0x00007ff56a9aa963 in g_main_loop_run () at pthread_create.c:679 +#3 0x00007ff56a4a5b71 in iothread_run (opaque=opaque@entry=0x555556e0c800) at iothread.c:82 +#4 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007ff56ac43353 in clone () + +Thread 2 (LWP 211752): +#0 0x00007ff56ac4007d in syscall () +#1 0x00007ff56a7d1e32 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /root/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait () at util/qemu-thread-posix.c:460 +#3 0x00007ff56a7dc0f2 in call_rcu_thread () at util/rcu.c:258 +#4 0x00007ff56a7d0f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007ff56ab95109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007ff56ac43353 in clone () + +Thread 1 (LWP 211751): +#0 __lll_lock_wait (futex=futex@entry=0x7ff56b447980 <qemu_global_mutex>, private=0) at lowlevellock.c:52 +#1 0x00007ff56ab97263 in __pthread_mutex_lock (mutex=mutex@entry=0x7ff56b447980 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x00007ff56a7d1087 in qemu_mutex_lock_impl (mutex=0x7ff56b447980 <qemu_global_mutex>, file=0x7ff56adcf1e3 "util/main-loop.c", line=238) at util/qemu-thread-posix.c:79 +#3 0x00007ff56a466f8e in qemu_mutex_lock_iothread_impl (file=file@entry=0x7ff56adcf1e3 "util/main-loop.c", line=line@entry=238) at /root/qemu/softmmu/cpus.c:1782 +#4 0x00007ff56a7e909d in os_host_main_loop_wait (timeout=951196740) at util/main-loop.c:238 +#5 main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:516 +#6 0x00007ff56a47876e in qemu_main_loop () at /root/qemu/softmmu/vl.c:1676 +#7 0x00007ff56a3a5b52 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /root/qemu/softmmu/main.c:49 +``` + +Here's what I get with 5.1.0-rc2 + +``` +(gdb) thread apply all bt + +Thread 5 (LWP 23730): +#0 0x00007f9ae6040ebb in ioctl () +#1 0x00007f9ae57cf98b in kvm_vcpu_ioctl (cpu=cpu@entry=0x555557539ea0, type=type@entry=44672) at /root/qemu/accel/kvm/kvm-all.c:2631 +#2 0x00007f9ae57cfac5 in kvm_cpu_exec (cpu=cpu@entry=0x555557539ea0) at /root/qemu/accel/kvm/kvm-all.c:2468 +#3 0x00007f9ae586703c in qemu_kvm_cpu_thread_fn (arg=0x555557539ea0) at /root/qemu/softmmu/cpus.c:1188 +#4 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555557539ea0) at /root/qemu/softmmu/cpus.c:1160 +#5 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007f9ae6045353 in clone () + +Thread 4 (LWP 23729): +#0 0x00007f9ae5fed337 in __strcmp_sse2 () +#1 0x00007f9ae5d9a8ad in g_str_equal () at pthread_create.c:679 +#2 0x00007f9ae5d99a9d in g_hash_table_lookup () at pthread_create.c:679 +#3 0x00007f9ae5ac728f in type_table_lookup (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:84 +#4 type_get_by_name (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:171 +#5 object_class_dynamic_cast (class=class@entry=0x5555572d1ac0, typename=typename@entry=0x7f9ae609c9dd "virtio-bus") at qom/object.c:879 +#6 0x00007f9ae5ac75b5 in object_class_dynamic_cast_assert (class=0x5555572d1ac0, typename=typename@entry=0x7f9ae609c9dd "virtio-bus", file=file@entry=0x7f9ae60a80b8 "/root/qemu/hw/virtio/virtio.c", line=line@entry=3290, + func=func@entry=0x7f9ae60a8c30 <__func__.31954> "virtio_queue_enabled") at qom/object.c:935 +#7 0x00007f9ae5817842 in virtio_queue_enabled (vdev=0x555558418be0, n=0) at /root/qemu/hw/virtio/virtio.c:3290 +#8 0x00007f9ae59c2837 in vhost_net_start_one (dev=0x555558418be0, net=0x5555574d8ca0) at hw/net/vhost_net.c:259 +#9 vhost_net_start (dev=dev@entry=0x555558418be0, ncs=0x55555842e030, total_queues=total_queues@entry=2) at hw/net/vhost_net.c:351 +#10 0x00007f9ae57f4d98 in virtio_net_vhost_status (status=<optimized out>, n=0x555558418be0) at /root/qemu/hw/net/virtio-net.c:268 +#11 virtio_net_set_status (vdev=0x555558418be0, status=<optimized out>) at /root/qemu/hw/net/virtio-net.c:349 +#12 0x00007f9ae5815bdb in virtio_set_status (vdev=vdev@entry=0x555558418be0, val=val@entry=7 '\a') at /root/qemu/hw/virtio/virtio.c:1956 +#13 0x00007f9ae5a5ddf0 in virtio_ioport_write (val=7, addr=18, opaque=0x555558410a50) at hw/virtio/virtio-pci.c:331 +#14 virtio_pci_config_write (opaque=0x555558410a50, addr=18, val=<optimized out>, size=<optimized out>) at hw/virtio/virtio-pci.c:455 +#15 0x00007f9ae5870b2a in memory_region_write_accessor (attrs=..., mask=255, shift=<optimized out>, size=1, value=0x7f99dfffd5f8, addr=<optimized out>, mr=0x555558411340) at /root/qemu/softmmu/memory.c:483 +#16 access_with_adjusted_size (attrs=..., mr=0x555558411340, access_fn=<optimized out>, access_size_max=<optimized out>, access_size_min=<optimized out>, size=1, value=0x7f99dfffd5f8, addr=18) + at /root/qemu/softmmu/memory.c:544 +#17 memory_region_dispatch_write (mr=mr@entry=0x555558411340, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=..., attrs@entry=...) at /root/qemu/softmmu/memory.c:1465 +#18 0x00007f9ae57ab4b2 in flatview_write_continue (fv=0x7f99d007ef80, addr=addr@entry=53394, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f9ae43f1000, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, + mr=0x555558411340) at /root/qemu/include/qemu/host-utils.h:164 +#19 0x00007f9ae57afc4d in flatview_write (len=1, buf=0x7f9ae43f1000, attrs=..., addr=53394, fv=<optimized out>) at /root/qemu/exec.c:3216 +#20 address_space_write (len=1, buf=0x7f9ae43f1000, attrs=..., addr=53394, as=0x7f9ae43f1000) at /root/qemu/exec.c:3307 +#21 address_space_rw (as=as@entry=0x7f9ae6846d60 <address_space_io>, addr=addr@entry=53394, attrs=attrs@entry=..., buf=0x7f9ae43f1000, len=len@entry=1, is_write=is_write@entry=true) at /root/qemu/exec.c:3317 +#22 0x00007f9ae57cfd5f in kvm_handle_io (count=1, size=1, direction=<optimized out>, data=<optimized out>, attrs=..., port=53394) at /root/qemu/accel/kvm/kvm-all.c:2262 +#23 kvm_cpu_exec (cpu=cpu@entry=0x5555574f3ac0) at /root/qemu/accel/kvm/kvm-all.c:2508 +#24 0x00007f9ae586703c in qemu_kvm_cpu_thread_fn (arg=0x5555574f3ac0) at /root/qemu/softmmu/cpus.c:1188 +#25 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x5555574f3ac0) at /root/qemu/softmmu/cpus.c:1160 +#26 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#27 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#28 0x00007f9ae6045353 in clone () + +Thread 3 (LWP 23728): +#0 0x00007f9ae603fd0f in poll () +#1 0x00007f9ae5dac5de in g_main_context_iterate.isra () at pthread_create.c:679 +#2 0x00007f9ae5dac963 in g_main_loop_run () at pthread_create.c:679 +#3 0x00007f9ae58a7b71 in iothread_run (opaque=opaque@entry=0x55555734b800) at iothread.c:82 +#4 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007f9ae6045353 in clone () + +Thread 2 (LWP 23723): +#0 0x00007f9ae604207d in syscall () +#1 0x00007f9ae5bd3e32 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /root/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait () at util/qemu-thread-posix.c:460 +#3 0x00007f9ae5bde0f2 in call_rcu_thread () at util/rcu.c:258 +#4 0x00007f9ae5bd2f13 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#5 0x00007f9ae5f97109 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007f9ae6045353 in clone () +---Type <return> to continue, or q <return> to quit--- + +Thread 1 (LWP 23722): +#0 __lll_lock_wait (futex=futex@entry=0x7f9ae6849980 <qemu_global_mutex>, private=0) at lowlevellock.c:52 +#1 0x00007f9ae5f99263 in __pthread_mutex_lock (mutex=mutex@entry=0x7f9ae6849980 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x00007f9ae5bd3087 in qemu_mutex_lock_impl (mutex=0x7f9ae6849980 <qemu_global_mutex>, file=0x7f9ae61d11e3 "util/main-loop.c", line=238) at util/qemu-thread-posix.c:79 +#3 0x00007f9ae5868f8e in qemu_mutex_lock_iothread_impl (file=file@entry=0x7f9ae61d11e3 "util/main-loop.c", line=line@entry=238) at /root/qemu/softmmu/cpus.c:1782 +#4 0x00007f9ae5beb09d in os_host_main_loop_wait (timeout=940584562) at util/main-loop.c:238 +#5 main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:516 +#6 0x00007f9ae587a76e in qemu_main_loop () at /root/qemu/softmmu/vl.c:1676 +#7 0x00007f9ae57a7b52 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /root/qemu/softmmu/main.c:49 +``` + + +Thanks for the information. + +It could be fixed by this commit upstream. + + +a48aaf882b100b30111b5c7c75e1d9e83fe76cfd ("virtio-pci: fix wrong index in virtio_pci_queue_enabled") + +Please try. + +Thanks + +Hi Jason, +See Comment#10 for trace -- 5.1.0-rc2 includes that fix... https://github.com/qemu/qemu/commit/a48aaf882b100b30111b5c7c75e1d9e83fe76cfd + +... so hang is still happening. + +Is there anything more I could do to help track this down? + +If even with that fix it's failing =and giving a similar back trace, then: + +Thread 4 (LWP 23729): +#0 0x00007f9ae5fed337 in __strcmp_sse2 () +#1 0x00007f9ae5d9a8ad in g_str_equal () at pthread_create.c:679 +#2 0x00007f9ae5d99a9d in g_hash_table_lookup () at pthread_create.c:679 +#3 0x00007f9ae5ac728f in type_table_lookup (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:84 +#4 type_get_by_name (name=0x7f9ae609c9dd "virtio-bus") at qom/object.c:171 +#5 object_class_dynamic_cast (class=class@entry=0x5555572d1ac0, typename=typename@entry=0x7f9ae609c9dd "virtio-bus") at qom/object.c:879 + +seems weird to me - why would you be stuck in a g_str_equal for any length of time (yet 2 of your backtraces both have it); yet the filename and symbol name don't really look like they're matching so I'm suspicious. +Have you got a minimal non-kata way to reproduce this? + + +Not currently, but let me try and setup just a simple qemu test + +This problem no longer occurs. I suspect it was an issue in my environment or possibly with the options I compiled QEMU with. This big/issue should be closed. + +er... This bug/issue should be closed. + + + diff --git a/results/classifier/105/KVM/1889945 b/results/classifier/105/KVM/1889945 new file mode 100644 index 00000000..bcd364b0 --- /dev/null +++ b/results/classifier/105/KVM/1889945 @@ -0,0 +1,161 @@ +KVM: 0.677 +vnc: 0.661 +other: 0.649 +network: 0.636 +mistranslation: 0.632 +boot: 0.628 +graphic: 0.624 +device: 0.621 +socket: 0.620 +instruction: 0.616 +semantic: 0.614 +assembly: 0.607 + +virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded + +Bug in QEMU 5.0.0: + +virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded. +If iommu_platform is disabled the guest immediately locks up as a result of the configured PCIe-Passthrough. + +Host system: +- Arch Linux amd64 +- AMD Ryzen Platform +- QEMU 5.0.0 + +Guest system: +- Windows Server 2019 (also happens in linux installations) +- PCIe GPU hostdev +- virtiofs passthrough + +Many thanks for any advice. + +QEMU LOG: +2020-07-28 19:20:07.197+0000: Starting external device: virtiofsd +/usr/lib/qemu/virtiofsd --fd=29 -o source=/viofstest +2020-07-28 19:20:07.207+0000: starting up libvirt version: 6.5.0, qemu version: 5.0.0, kernel: 5.7.10-arch1-1, hostname: mspc +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-7-win \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-7-win/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-7-win/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-7-win/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=win,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-win/master-key.aes \ +-blockdev '{"driver":"file","filename":"/usr/share/ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,kernel_irqchip=on,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=whatever,kvm=off \ +-m 2048 \ +-overcommit mem-lock=off \ +-smp 8,sockets=8,cores=1,threads=1 \ +-object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/7-win,share=yes,size=2147483648 \ +-numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \ +-uuid c8efa194-52f8-4526-a0f8-29a254839b55 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=29,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot menu=off,strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-pci-bridge,id=pci.2,bus=pci.1,addr=0x0 \ +-device pcie-root-port,port=0x11,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x5 \ +-device pcie-root-port,port=0x16,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x6 \ +-device pcie-root-port,port=0x17,chassis=9,id=pci.9,bus=pcie.0,addr=0x2.0x7 \ +-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,multifunction=on,addr=0x3 \ +-device pcie-root-port,port=0x19,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x1 \ +-device pcie-root-port,port=0x1a,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x2 \ +-device pcie-root-port,port=0x8,chassis=13,id=pci.13,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x9,chassis=14,id=pci.14,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0xa,chassis=15,id=pci.15,bus=pcie.0,addr=0x1.0x2 \ +-device pcie-root-port,port=0xb,chassis=16,id=pci.16,bus=pcie.0,addr=0x1.0x3 \ +-device nec-usb-xhci,id=usb,bus=pci.7,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.14,addr=0x0 \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/ssd/windows","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \ +-device virtio-blk-pci,bus=pci.3,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/ssd/windows-ssdgames1","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-device virtio-blk-pci,bus=pci.9,addr=0x0,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/hdd/win-games1","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \ +-device virtio-blk-pci,bus=pci.13,addr=0x0,drive=libvirt-1-format,id=virtio-disk2,write-cache=on \ +-chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-7-win/fs0-fs.sock \ +-device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=viofstest,iommu_platform=on,ats=on,bus=pci.15,addr=0x0 \ +-netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=34 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fb:0c:28,bus=pci.10,addr=0x0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-device virtio-keyboard-pci,id=input0,bus=pci.12,addr=0x0 \ +-device virtio-tablet-pci,id=input1,bus=pci.8,addr=0x0 \ +-device virtio-mouse-pci,id=input2,bus=pci.11,addr=0x0 \ +-device ich9-intel-hda,id=sound0,bus=pci.2,addr=0x1 \ +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-device vfio-pci,host=0000:08:00.0,id=hostdev0,bus=pci.5,addr=0x0,rombar=1 \ +-device vfio-pci,host=0000:08:00.1,id=hostdev1,bus=pci.6,addr=0x0,rombar=1 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \ +-object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:0a:00.3-usb-0:3:1.0-event-kbd,grab_all=on,repeat=on \ +-object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:0a:00.3-usb-0:4:1.0-event-mouse \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: high-privileges +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: custom-argv +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: host-cpu +<--- VIOFS DRIVER GETS LOADED HERE ---> +2020-07-28T19:20:57.568089Z qemu-system-x86_64: Failed to read msg header. Read -1 instead of 12. Original request 1566376224. +2020-07-28T19:20:57.568120Z qemu-system-x86_64: Fail to update device iotlb +2020-07-28T19:20:57.568147Z qemu-system-x86_64: Failed to read msg header. Read 0 instead of 12. Original request 1566376528. +2020-07-28T19:20:57.568151Z qemu-system-x86_64: Fail to update device iotlb +2020-07-28T19:20:57.568153Z qemu-system-x86_64: Failed to set msg fds. +2020-07-28T19:20:57.568156Z qemu-system-x86_64: vhost_set_vring_call failed: Invalid argument (22) +2020-07-28T19:20:57.568160Z qemu-system-x86_64: Failed to set msg fds. +2020-07-28T19:20:57.568162Z qemu-system-x86_64: vhost_set_vring_call failed: Invalid argument (22) +2020-07-28T19:20:57.568296Z qemu-system-x86_64: Failed to read from slave. + +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" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus 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/105/KVM/1891354 b/results/classifier/105/KVM/1891354 new file mode 100644 index 00000000..e29b9f35 --- /dev/null +++ b/results/classifier/105/KVM/1891354 @@ -0,0 +1,406 @@ +KVM: 0.733 +other: 0.722 +instruction: 0.680 +device: 0.620 +graphic: 0.620 +semantic: 0.571 +mistranslation: 0.561 +vnc: 0.559 +assembly: 0.529 +network: 0.502 +boot: 0.477 +socket: 0.470 + +Heap-use-after-free in usb_packet_unmap + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +-trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc0202 +outl 0xcf8 0x80001004 +outl 0xcfc 0x1c77695e +writel 0xc0040 0xffffd855 +writeq 0xc2000 0xff05140100000000 +write 0x1d 0x1 0x27 +write 0x2d 0x1 0x2e +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x05 +write 0x17276 0x1 0x72 +write 0x17278 0x1 0x02 +write 0x3d 0x1 0x27 +write 0x40 0x1 0x2e +write 0x41 0x1 0x72 +write 0x42 0x1 0x01 +write 0x4d 0x1 0x2e +write 0x4f 0x1 0x01 +write 0x2007c 0x1 0xc7 +writeq 0xc2000 0x5c05140100000000 +write 0x20070 0x1 0x80 +write 0x20078 0x1 0x08 +write 0x2007c 0x1 0xfe +write 0x2007d 0x1 0x08 +write 0x20081 0x1 0xff +write 0x20082 0x1 0x0b +write 0x20089 0x1 0x8c +write 0x2008d 0x1 0x04 +write 0x2009d 0x1 0x10 +writeq 0xc2000 0x2505ef019e092f00 +EOF + +20091==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000045030 at pc 0x55db79edeef2 bp 0x7ffc4020b2b0 sp 0x7ffc4020b2a8 +READ of size 4 at 0x611000045030 thread T0 + #0 0x55db79edeef1 in usb_packet_unmap hw/usb/libhw.c:64:28 + #1 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 + #2 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #3 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #4 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #5 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #10 0x55db78cfee6b in flatview_write exec.c:3216:14 + #11 0x55db78cfee6b in address_space_write exec.c:3308:18 + #12 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 + #13 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #14 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 + #15 0x7fc5d7f1a897 in g_main_context_dispatch + #16 0x55db7aa571b3 in glib_pollfds_poll util/main-loop.c:217:9 + #17 0x55db7aa571b3 in os_host_main_loop_wait util/main-loop.c:240:5 + #18 0x55db7aa571b3 in main_loop_wait util/main-loop.c:516:11 + #19 0x55db79315008 in qemu_main_loop softmmu/vl.c:1676:9 + #20 0x55db7a8860fd in main softmmu/main.c:49:5 + +0x611000045030 is located 48 bytes inside of 256-byte region [0x611000045000,0x611000045100) +freed by thread T0 here: + #0 0x55db78cac16d in free (build/i386-softmmu/qemu-system-i386+0x250e16d) + #1 0x55db79f7c0e8 in xhci_ep_nuke_xfers hw/usb/hcd-xhci.c:1252:9 + #2 0x55db79f7b454 in xhci_disable_ep hw/usb/hcd-xhci.c:1279:5 + #3 0x55db79f79af7 in xhci_disable_slot hw/usb/hcd-xhci.c:2048:13 + #4 0x55db79f5aea3 in xhci_reset hw/usb/hcd-xhci.c:2706:9 + #5 0x55db79f82f49 in xhci_oper_write hw/usb/hcd-xhci.c:2966:13 + #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #10 0x55db78cfee6b in flatview_write exec.c:3216:14 + #11 0x55db78cfee6b in address_space_write exec.c:3308:18 + #12 0x55db78d01fe7 in address_space_unmap exec.c:3634:9 + #13 0x55db79edebbb in dma_memory_unmap include/sysemu/dma.h:145:5 + #14 0x55db79edebbb in usb_packet_unmap hw/usb/libhw.c:65:9 + #15 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 + #16 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #17 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #18 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #19 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #20 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #21 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #22 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #23 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #24 0x55db78cfee6b in flatview_write exec.c:3216:14 + #25 0x55db78cfee6b in address_space_write exec.c:3308:18 + #26 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 + #27 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #28 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 + #29 0x7fc5d7f1a897 in g_main_context_dispatch + +previously allocated by thread T0 here: + #0 0x55db78cac562 in calloc (build/i386-softmmu/qemu-system-i386+0x250e562) + #1 0x7fc5d7f20548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) + #2 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #3 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #4 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #5 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #6 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #7 0x55db78cfee6b in flatview_write exec.c:3216:14 + #8 0x55db78cfee6b in address_space_write exec.c:3308:18 + #9 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 + #10 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #11 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 + #12 0x7fc5d7f1a897 in g_main_context_dispatch + +-Alex + +On 200813 0024, Li Qiang wrote: +> Alexander Bulekov <email address hidden> 于2020年8月13日周四 上午12:21写道： +> > +> > Public bug reported: +> > +> > Hello, +> > Reproducer: +> > +> > cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +> > -trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +> > -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +> > -nodefaults -nographic -qtest stdio +> > outl 0xcf8 0x80001010 +> > outl 0xcfc 0xc0202 +> > outl 0xcf8 0x80001004 +> > outl 0xcfc 0x1c77695e +> > writel 0xc0040 0xffffd855 +> > writeq 0xc2000 0xff05140100000000 +> > write 0x1d 0x1 0x27 +> > write 0x2d 0x1 0x2e +> > write 0x17232 0x1 0x03 +> > write 0x17254 0x1 0x05 +> > write 0x17276 0x1 0x72 +> > write 0x17278 0x1 0x02 +> > write 0x3d 0x1 0x27 +> > write 0x40 0x1 0x2e +> > write 0x41 0x1 0x72 +> > write 0x42 0x1 0x01 +> > write 0x4d 0x1 0x2e +> > write 0x4f 0x1 0x01 +> > write 0x2007c 0x1 0xc7 +> > writeq 0xc2000 0x5c05140100000000 +> > write 0x20070 0x1 0x80 +> > write 0x20078 0x1 0x08 +> > write 0x2007c 0x1 0xfe +> > write 0x2007d 0x1 0x08 +> > write 0x20081 0x1 0xff +> > write 0x20082 0x1 0x0b +> > write 0x20089 0x1 0x8c +> > write 0x2008d 0x1 0x04 +> > write 0x2009d 0x1 0x10 +> > writeq 0xc2000 0x2505ef019e092f00 +> > EOF +> > +> > 20091==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000045030 at pc 0x55db79edeef2 bp 0x7ffc4020b2b0 sp 0x7ffc4020b2a8 +> > READ of size 4 at 0x611000045030 thread T0 +> > #0 0x55db79edeef1 in usb_packet_unmap hw/usb/libhw.c:64:28 +> > #1 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 +> > #2 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 +> > #3 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 +> > #4 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 +> > #5 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +> > #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #10 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #11 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #12 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 +> > #13 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 +> > #14 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 +> > #15 0x7fc5d7f1a897 in g_main_context_dispatch +> > #16 0x55db7aa571b3 in glib_pollfds_poll util/main-loop.c:217:9 +> > #17 0x55db7aa571b3 in os_host_main_loop_wait util/main-loop.c:240:5 +> > #18 0x55db7aa571b3 in main_loop_wait util/main-loop.c:516:11 +> > #19 0x55db79315008 in qemu_main_loop softmmu/vl.c:1676:9 +> > #20 0x55db7a8860fd in main softmmu/main.c:49:5 +> > +> > 0x611000045030 is located 48 bytes inside of 256-byte region [0x611000045000,0x611000045100) +> > freed by thread T0 here: +> > #0 0x55db78cac16d in free (build/i386-softmmu/qemu-system-i386+0x250e16d) +> > #1 0x55db79f7c0e8 in xhci_ep_nuke_xfers hw/usb/hcd-xhci.c:1252:9 +> > #2 0x55db79f7b454 in xhci_disable_ep hw/usb/hcd-xhci.c:1279:5 +> > #3 0x55db79f79af7 in xhci_disable_slot hw/usb/hcd-xhci.c:2048:13 +> > #4 0x55db79f5aea3 in xhci_reset hw/usb/hcd-xhci.c:2706:9 +> > #5 0x55db79f82f49 in xhci_oper_write hw/usb/hcd-xhci.c:2966:13 +> > #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #10 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #11 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #12 0x55db78d01fe7 in address_space_unmap exec.c:3634:9 +> > #13 0x55db79edebbb in dma_memory_unmap include/sysemu/dma.h:145:5 +> > #14 0x55db79edebbb in usb_packet_unmap hw/usb/libhw.c:65:9 +> > #15 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 +> > #16 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 +> > #17 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 +> > #18 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 +> > #19 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +> > #20 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #21 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #22 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #23 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #24 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #25 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #26 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 +> > #27 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 +> > #28 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 +> > #29 0x7fc5d7f1a897 in g_main_context_dispatch +> > +> +> This issue as far as I can see, is the DMA to MMIO issue. + +Another one - Interesting... +So it joins these: +https://bugs.launchpad.net/qemu/+bug/1888606 +https://bugs.launchpad.net/qemu/+bug/1886362 + +Could this one be dealt with by moving xhci_reset into a BH? +-Alex + +> Thanks, +> Li Qiang +> +> +> > previously allocated by thread T0 here: +> > #0 0x55db78cac562 in calloc (build/i386-softmmu/qemu-system-i386+0x250e562) +> > #1 0x7fc5d7f20548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) +> > #2 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +> > #3 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #4 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #5 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #6 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #7 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #8 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #9 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 +> > #10 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 +> > #11 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 +> > #12 0x7fc5d7f1a897 in g_main_context_dispatch +> > +> > -Alex +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1891354 +> > +> > Title: +> > Heap-use-after-free in usb_packet_unmap +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Hello, +> > Reproducer: +> > +> > cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +> > -trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +> > -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +> > -nodefaults -nographic -qtest stdio +> > outl 0xcf8 0x80001010 +> > outl 0xcfc 0xc0202 +> > outl 0xcf8 0x80001004 +> > outl 0xcfc 0x1c77695e +> > writel 0xc0040 0xffffd855 +> > writeq 0xc2000 0xff05140100000000 +> > write 0x1d 0x1 0x27 +> > write 0x2d 0x1 0x2e +> > write 0x17232 0x1 0x03 +> > write 0x17254 0x1 0x05 +> > write 0x17276 0x1 0x72 +> > write 0x17278 0x1 0x02 +> > write 0x3d 0x1 0x27 +> > write 0x40 0x1 0x2e +> > write 0x41 0x1 0x72 +> > write 0x42 0x1 0x01 +> > write 0x4d 0x1 0x2e +> > write 0x4f 0x1 0x01 +> > write 0x2007c 0x1 0xc7 +> > writeq 0xc2000 0x5c05140100000000 +> > write 0x20070 0x1 0x80 +> > write 0x20078 0x1 0x08 +> > write 0x2007c 0x1 0xfe +> > write 0x2007d 0x1 0x08 +> > write 0x20081 0x1 0xff +> > write 0x20082 0x1 0x0b +> > write 0x20089 0x1 0x8c +> > write 0x2008d 0x1 0x04 +> > write 0x2009d 0x1 0x10 +> > writeq 0xc2000 0x2505ef019e092f00 +> > EOF +> > +> > 20091==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000045030 at pc 0x55db79edeef2 bp 0x7ffc4020b2b0 sp 0x7ffc4020b2a8 +> > READ of size 4 at 0x611000045030 thread T0 +> > #0 0x55db79edeef1 in usb_packet_unmap hw/usb/libhw.c:64:28 +> > #1 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 +> > #2 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 +> > #3 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 +> > #4 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 +> > #5 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +> > #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #10 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #11 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #12 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 +> > #13 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 +> > #14 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 +> > #15 0x7fc5d7f1a897 in g_main_context_dispatch +> > #16 0x55db7aa571b3 in glib_pollfds_poll util/main-loop.c:217:9 +> > #17 0x55db7aa571b3 in os_host_main_loop_wait util/main-loop.c:240:5 +> > #18 0x55db7aa571b3 in main_loop_wait util/main-loop.c:516:11 +> > #19 0x55db79315008 in qemu_main_loop softmmu/vl.c:1676:9 +> > #20 0x55db7a8860fd in main softmmu/main.c:49:5 +> > +> > 0x611000045030 is located 48 bytes inside of 256-byte region [0x611000045000,0x611000045100) +> > freed by thread T0 here: +> > #0 0x55db78cac16d in free (build/i386-softmmu/qemu-system-i386+0x250e16d) +> > #1 0x55db79f7c0e8 in xhci_ep_nuke_xfers hw/usb/hcd-xhci.c:1252:9 +> > #2 0x55db79f7b454 in xhci_disable_ep hw/usb/hcd-xhci.c:1279:5 +> > #3 0x55db79f79af7 in xhci_disable_slot hw/usb/hcd-xhci.c:2048:13 +> > #4 0x55db79f5aea3 in xhci_reset hw/usb/hcd-xhci.c:2706:9 +> > #5 0x55db79f82f49 in xhci_oper_write hw/usb/hcd-xhci.c:2966:13 +> > #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #10 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #11 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #12 0x55db78d01fe7 in address_space_unmap exec.c:3634:9 +> > #13 0x55db79edebbb in dma_memory_unmap include/sysemu/dma.h:145:5 +> > #14 0x55db79edebbb in usb_packet_unmap hw/usb/libhw.c:65:9 +> > #15 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 +> > #16 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 +> > #17 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 +> > #18 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 +> > #19 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +> > #20 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #21 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #22 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #23 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #24 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #25 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #26 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 +> > #27 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 +> > #28 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 +> > #29 0x7fc5d7f1a897 in g_main_context_dispatch +> > +> > previously allocated by thread T0 here: +> > #0 0x55db78cac562 in calloc (build/i386-softmmu/qemu-system-i386+0x250e562) +> > #1 0x7fc5d7f20548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) +> > #2 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +> > #3 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 +> > #4 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 +> > #5 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c +> > #6 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 +> > #7 0x55db78cfee6b in flatview_write exec.c:3216:14 +> > #8 0x55db78cfee6b in address_space_write exec.c:3308:18 +> > #9 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 +> > #10 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 +> > #11 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 +> > #12 0x7fc5d7f1a897 in g_main_context_dispatch +> > +> > -Alex +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1891354/+subscriptions +> > +> + + +Still reproduces with current version of QEMU (if it has been built with Clang + asan enabled). Marking as "Confirmed" + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/540 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/105/KVM/1892963 b/results/classifier/105/KVM/1892963 new file mode 100644 index 00000000..319685cb --- /dev/null +++ b/results/classifier/105/KVM/1892963 @@ -0,0 +1,339 @@ +KVM: 0.838 +other: 0.826 +mistranslation: 0.798 +graphic: 0.770 +vnc: 0.722 +device: 0.718 +instruction: 0.708 +assembly: 0.682 +semantic: 0.638 +network: 0.615 +boot: 0.607 +socket: 0.595 + +Heap-use-after-free in put_dwords through ehci_flush_qh + +Hello, +Reproducer: + +cat << EOF | ./qemu-system-i386 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,\ +multifunction=on,id=ich9-ehci-1 \ +-drive if=none,id=usbcdrom,media=cdrom \ +-device usb-storage,bus=ich9-ehci-1.0,\ +port=2,drive=usbcdrom \ +-display none -nodefaults -qtest stdio -accel qtest +outl 0xcf8 0x8000ef02 +outl 0xcfc 0xfbff0061 +outl 0xcf8 0x8000ef11 +outl 0xcfc 0x60606060 +writeq 0x60606065 0xb70560ff84ffff7f +writeq 0x60606065 0xff0004fe050000ff +writeq 0x60606020 0xff015e5c057b0039 +writeq 0x60606033 0x846c8a0200000611 +write 0x2000004 0x4 0x4a606060 +write 0x8 0x4 0x97a98095 +write 0x0 0x4 0x4a606060 +write 0x4 0x4 0x97a98095 +write 0xc 0x4 0x4a606060 +write 0x10 0x4 0x97a98095 +write 0x14 0x4 0x4a606060 +write 0x18 0x4 0x97a98095 +write 0x1c 0x4 0x4a606060 +clock_step +EOF + +The trace: +797726@1598407357.169284:usb_port_claim bus 0, port 2 +797726@1598407357.169585:usb_port_attach bus 0, port 2, devspeed full+high+super, portspeed high +797726@1598407357.169598:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.169608:usb_ehci_irq level 0, frindex 0x0000, sts 0x4, mask 0x0 +797726@1598407357.186943:usb_ehci_reset === RESET === +797726@1598407357.186960:usb_ehci_port_detach detach port #1, owner ehci +797726@1598407357.186968:usb_ehci_irq level 0, frindex 0x0000, sts 0x4, mask 0x0 +797726@1598407357.186976:usb_ehci_irq level 0, frindex 0x0000, sts 0x1000, mask 0x0 +797726@1598407357.186984:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.186989:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0 +[R +0.073737] outl 0xcf8 0x8000ef02 +OK +[S +0.073774] OK +[R +0.073801] outl 0xcfc 0xfbff0061 +OK +[S +0.075074] OK +[R +0.075108] outl 0xcf8 0x8000ef11 +OK +[S +0.075126] OK +[R +0.075135] outl 0xcfc 0x60606060 +OK +[S +0.076290] OK +[R +0.076317] writeq 0x60606065 0xb70560ff84ffff7f +797726@1598407357.194959:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x560ff84 +797726@1598407357.194967:usb_ehci_port_reset reset port #1 - 1 +797726@1598407357.194971:usb_ehci_port_suspend port #1 +797726@1598407357.194975:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x601183 (old: 0x1003) +OK +[S +0.076363] OK +[R +0.076377] writeq 0x60606065 0xff0004fe050000ff +797726@1598407357.195005:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x4fe05 +797726@1598407357.195011:usb_ehci_port_reset reset port #1 - 0 +797726@1598407357.195019:usb_ehci_port_detach detach port #1, owner ehci +797726@1598407357.195026:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0 +797726@1598407357.195034:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.195038:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0 +797726@1598407357.195049:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x1005 (old: 0x601183) +OK +[S +0.076439] OK +[R +0.076457] writeq 0x60606020 0xff015e5c057b0039 +797726@1598407357.195087:usb_ehci_opreg_write wr mmio 0x0020 [USBCMD] = 0x57b0039 +attempt to set frame list size -- value 8 +797726@1598407357.195097:usb_ehci_usbsts usbsts HALT 0 +797726@1598407357.195105:usb_ehci_opreg_change ch mmio 0x0020 [USBCMD] = 0x57b0031 (old: 0x80000) +797726@1598407357.195111:usb_ehci_opreg_write wr mmio 0x0024 [USBSTS] = 0xff015e5c +797726@1598407357.195117:usb_ehci_usbsts usbsts PCD 0 +797726@1598407357.195120:usb_ehci_usbsts usbsts FLR 0 +797726@1598407357.195124:usb_ehci_usbsts usbsts HSE 0 +797726@1598407357.195127:usb_ehci_irq level 0, frindex 0x0000, sts 0x0, mask 0x0 +797726@1598407357.195132:usb_ehci_opreg_change ch mmio 0x0024 [USBSTS] = 0x0 (old: 0x4) +OK +[S +0.076519] OK +[R +0.076534] writeq 0x60606033 0x846c8a0200000611 +797726@1598407357.195164:usb_ehci_opreg_write wr mmio 0x0034 [P-LIST BASE] = 0x2000006 +ehci: PERIODIC list base register set while periodic schedule + is enabled and HC is enabled +797726@1598407357.195174:usb_ehci_opreg_change ch mmio 0x0034 [P-LIST BASE] = 0x2000006 (old: 0x0) +OK +[S +0.076562] OK +[R +0.076574] write 0x2000004 0x4 0x4a606060 +OK +[S +0.076855] OK +[R +0.076869] write 0x8 0x4 0x97a98095 +OK +[S +0.077214] OK +[R +0.077225] write 0x0 0x4 0x4a606060 +OK +[S +0.077233] OK +[R +0.077242] write 0x4 0x4 0x97a98095 +OK +[S +0.077250] OK +[R +0.077258] write 0xc 0x4 0x4a606060 +OK +[S +0.077266] OK +[R +0.077274] write 0x10 0x4 0x97a98095 +OK +[S +0.077281] OK +[R +0.077289] write 0x14 0x4 0x4a606060 +OK +[S +0.077295] OK +[R +0.077304] write 0x18 0x4 0x97a98095 +OK +[S +0.077310] OK +[R +0.077325] write 0x1c 0x4 0x4a606060 +OK +[S +0.077333] OK +[R +0.077340] clock_step +OK 27462700 +[S +0.077415] OK 27462700 +797726@1598407357.196115:usb_ehci_state periodic schedule ACTIVE +797726@1598407357.196123:usb_ehci_usbsts usbsts PSS 1 +797726@1598407357.196137:usb_ehci_state periodic schedule FETCH ENTRY +797726@1598407357.196145:usb_ehci_state periodic schedule FETCH QH +797726@1598407357.196154:usb_ehci_queue_action q 0x60d0000050b0: alloc +797726@1598407357.196168:usb_ehci_opreg_read rd mmio 0x0040 [unknown] = 0x0 +797726@1598407357.196176:usb_ehci_opreg_read rd mmio 0x0044 [unknown] = 0x0 +797726@1598407357.196182:usb_ehci_opreg_read rd mmio 0x0048 [unknown] = 0x0 +797726@1598407357.196188:usb_ehci_opreg_read rd mmio 0x004c [unknown] = 0x0 +797726@1598407357.196195:usb_ehci_opreg_read rd mmio 0x0050 [unknown] = 0x0 +797726@1598407357.196201:usb_ehci_opreg_read rd mmio 0x0054 [unknown] = 0x0 +797726@1598407357.196206:usb_ehci_opreg_read rd mmio 0x0058 [unknown] = 0x0 +797726@1598407357.196211:usb_ehci_opreg_read rd mmio 0x005c [unknown] = 0x0 +797726@1598407357.196217:usb_ehci_opreg_read rd mmio 0x0060 [CONFIGFLAG] = 0x0 +797726@1598407357.196224:usb_ehci_portsc_read rd mmio 0x0044 [port 0] = 0x1000 +797726@1598407357.196230:usb_ehci_portsc_read rd mmio 0x0048 [port 1] = 0x1005 +797726@1598407357.196237:usb_ehci_portsc_read rd mmio 0x004c [port 2] = 0x1000 +797726@1598407357.196243:usb_ehci_qh_ptrs q 0x60d0000050b0 - QH @ 0x60606040: next 0x00000000 qtds 0x00000000,0x00000000,0x00000000 +797726@1598407357.196249:usb_ehci_qh_fields QH @ 0x60606040 - rl 0, mplen 0, eps 0, ep 0, dev 0 +797726@1598407357.196255:usb_ehci_qh_bits QH @ 0x60606040 - c 0, h 0, dtc 0, i 0 +797726@1598407357.196262:usb_ehci_queue_action q 0x60d0000050b0: reset +797726@1598407357.196275:usb_ehci_state periodic schedule ADVANCEQUEUE +797726@1598407357.196281:usb_ehci_state periodic schedule FETCH QTD +797726@1598407357.196300:usb_ehci_qtd_ptrs q 0x60d0000050b0 - QTD @ 0x00000000: next 0x6060604a altnext 0x9580a997 +797726@1598407357.196306:usb_ehci_qtd_fields QTD @ 0x00000000 - tbytes 5504, cpage 2, cerr 2, pid 1 +797726@1598407357.196311:usb_ehci_qtd_bits QTD @ 0x00000000 - ioc 1, active 1, halt 0, babble 1, xacterr 0 +797726@1598407357.196323:usb_ehci_packet_action q 0x60d0000050b0 p 0x611000044380: alloc +797726@1598407357.196327:usb_ehci_state periodic schedule EXECUTE +797726@1598407357.196346:usb_ehci_opreg_write wr mmio 0x004c [unknown] = 0x0 +797726@1598407357.196351:usb_ehci_opreg_change ch mmio 0x004c [unknown] = 0x0 (old: 0x0) +797726@1598407357.196359:usb_ehci_opreg_write wr mmio 0x0050 [unknown] = 0x6060604a +797726@1598407357.196363:usb_ehci_opreg_change ch mmio 0x0050 [unknown] = 0x6060604a (old: 0x0) +797726@1598407357.196370:usb_ehci_opreg_write wr mmio 0x0054 [unknown] = 0x9580a981 +797726@1598407357.196374:usb_ehci_opreg_change ch mmio 0x0054 [unknown] = 0x9580a981 (old: 0x0) +797726@1598407357.196380:usb_ehci_opreg_write wr mmio 0x0058 [unknown] = 0x1580a997 +797726@1598407357.196385:usb_ehci_opreg_change ch mmio 0x0058 [unknown] = 0x1580a997 (old: 0x0) +797726@1598407357.196392:usb_ehci_opreg_write wr mmio 0x005c [unknown] = 0x6060604a +797726@1598407357.196396:usb_ehci_opreg_change ch mmio 0x005c [unknown] = 0x6060604a (old: 0x0) +797726@1598407357.196403:usb_ehci_opreg_write wr mmio 0x0060 [CONFIGFLAG] = 0x9580a900 +797726@1598407357.196407:usb_ehci_opreg_change ch mmio 0x0060 [CONFIGFLAG] = 0x0 (old: 0x0) +797726@1598407357.196415:usb_ehci_portsc_write wr mmio 0x0044 [port 0] = 0x60606040 +797726@1598407357.196422:usb_ehci_portsc_change ch mmio 0x0044 [port 0] = 0x601040 (old: 0x1000) +797726@1598407357.196428:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x9580a997 +797726@1598407357.196432:usb_ehci_port_reset reset port #1 - 1 +797726@1598407357.196437:usb_ehci_port_suspend port #1 +797726@1598407357.196441:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x1185 (old: 0x1005) +797726@1598407357.196448:usb_ehci_portsc_write wr mmio 0x004c [port 2] = 0x6060604a +797726@1598407357.196453:usb_ehci_portsc_change ch mmio 0x004c [port 2] = 0x601040 (old: 0x1000) +797726@1598407357.196474:usb_packet_state_change bus 0, port 2, ep 0, packet 0x6110000443c0, state undef -> setup +797726@1598407357.196505:usb_ehci_opreg_write wr mmio 0x004c [unknown] = 0xbebebebe +797726@1598407357.196509:usb_ehci_opreg_change ch mmio 0x004c [unknown] = 0xbebebebe (old: 0x0) +797726@1598407357.196516:usb_ehci_opreg_write wr mmio 0x0050 [unknown] = 0xbebebebe +797726@1598407357.196520:usb_ehci_opreg_change ch mmio 0x0050 [unknown] = 0xbebebebe (old: 0x6060604a) +797726@1598407357.196527:usb_ehci_opreg_write wr mmio 0x0054 [unknown] = 0xbebebebe +797726@1598407357.196530:usb_ehci_opreg_change ch mmio 0x0054 [unknown] = 0xbebebebe (old: 0x9580a981) +797726@1598407357.196540:usb_ehci_opreg_write wr mmio 0x0058 [unknown] = 0xbebebebe +797726@1598407357.196544:usb_ehci_opreg_change ch mmio 0x0058 [unknown] = 0xbebebebe (old: 0x1580a997) +797726@1598407357.196550:usb_ehci_opreg_write wr mmio 0x005c [unknown] = 0xbebebebe +797726@1598407357.196554:usb_ehci_opreg_change ch mmio 0x005c [unknown] = 0xbebebebe (old: 0x6060604a) +797726@1598407357.196560:usb_ehci_opreg_write wr mmio 0x0060 [CONFIGFLAG] = 0xbebebebe +797726@1598407357.196563:usb_ehci_opreg_change ch mmio 0x0060 [CONFIGFLAG] = 0x0 (old: 0x0) +797726@1598407357.196569:usb_ehci_portsc_write wr mmio 0x0044 [port 0] = 0xbebebebe +797726@1598407357.196573:usb_ehci_port_suspend port #0 +797726@1598407357.196577:usb_ehci_port_resume port #0 +797726@1598407357.196580:usb_ehci_portsc_change ch mmio 0x0044 [port 0] = 0x301000 (old: 0x601040) +797726@1598407357.196586:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0xbebebebe +797726@1598407357.196590:usb_ehci_port_reset reset port #1 - 0 +797726@1598407357.196596:usb_ehci_port_detach detach port #1, owner ehci +797726@1598407357.196602:usb_ehci_queue_action q 0x60d0000050b0: free +797726@1598407357.196606:usb_ehci_queue_action q 0x60d0000050b0: cancel +797726@1598407357.196610:usb_ehci_packet_action q 0x60d0000050b0 p 0x611000044380: free +797726@1598407357.196626:usb_ehci_irq level 0, frindex 0x0008, sts 0x4004, mask 0x0 +797726@1598407357.196636:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD +797726@1598407357.196642:usb_ehci_irq level 0, frindex 0x0008, sts 0x4004, mask 0x0 +797726@1598407357.196655:usb_ehci_port_suspend port #1 +797726@1598407357.196659:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x301085 (old: 0x1185) +797726@1598407357.196669:usb_ehci_portsc_write wr mmio 0x004c [port 2] = 0xbebebebe +797726@1598407357.196674:usb_ehci_port_suspend port #2 +797726@1598407357.196679:usb_ehci_port_resume port #2 +797726@1598407357.196684:usb_ehci_portsc_change ch mmio 0x004c [port 2] = 0x301000 (old: 0x601040) +797726@1598407357.196694:usb_ehci_portsc_write wr mmio 0x0050 [port 3] = 0xbebebebe +797726@1598407357.196699:usb_ehci_port_suspend port #3 +797726@1598407357.196704:usb_ehci_portsc_change ch mmio 0x0050 [port 3] = 0x301080 (old: 0x1000) +797726@1598407357.196712:usb_ehci_portsc_write wr mmio 0x0054 [port 4] = 0xbebebebe +797726@1598407357.196716:usb_ehci_port_suspend port #4 +797726@1598407357.196718:usb_ehci_portsc_change ch mmio 0x0054 [port 4] = 0x301080 (old: 0x1000) +797726@1598407357.196724:usb_ehci_portsc_write wr mmio 0x0058 [port 5] = 0xbebebebe +797726@1598407357.196729:usb_ehci_port_suspend port #5 +797726@1598407357.196733:usb_ehci_portsc_change ch mmio 0x0058 [port 5] = 0x301080 (old: 0x1000) +================================================================= +==797726==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110000443e8 at pc 0x5574af0ef59d bp 0x7fff5b343a00 sp 0x7fff5b3439f8 +READ of size 4 at 0x6110000443e8 thread T0 + #0 0x5574af0ef59c in usb_packet_unmap /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:64:28 + #1 0x5574af0ee924 in usb_packet_map /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:54:5 + #2 0x5574ae630c2f in ehci_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1376:9 + #3 0x5574ae619cfe in ehci_state_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1942:13 + #4 0x5574ae60e8d9 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2083:21 + #5 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9 + #6 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17 + #7 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5 + #8 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13 + #9 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5 + #10 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5 + #11 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc) + #12 0x5574b2339c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #13 0x5574b2337567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #14 0x5574b2336f47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #15 0x5574b0b1508d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #16 0x5574ae4a751c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #17 0x7f44ce1e5cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #18 0x5574ae3fccf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +0x6110000443e8 is located 104 bytes inside of 248-byte region [0x611000044380,0x611000044478) +freed by thread T0 here: + #0 0x5574ae4751bd in free (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d291bd) + #1 0x5574ae5e71a1 in ehci_free_packet /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:541:5 + #2 0x5574ae5e3662 in ehci_cancel_queue /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:584:9 + #3 0x5574ae5e174c in ehci_free_queue /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:611:17 + #4 0x5574ae608300 in ehci_queues_rip_device /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:674:9 + #5 0x5574ae6034ba in ehci_detach /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:732:5 + #6 0x5574af06427f in usb_detach /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:70:5 + #7 0x5574af064607 in usb_port_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:79:5 + #8 0x5574ae63af7a in ehci_port_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:993:13 + #9 0x5574b0e31de0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #10 0x5574b0e312bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #11 0x5574b0e2ef70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #12 0x5574b0a8d8a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #13 0x5574b0a76878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #14 0x5574b0a763a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #15 0x5574b0a7dff7 in address_space_unmap /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3634:9 + #16 0x5574af0f0262 in dma_memory_unmap /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:145:5 + #17 0x5574af0f0143 in usb_packet_unmap /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:65:9 + #18 0x5574af0ee924 in usb_packet_map /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:54:5 + #19 0x5574ae630c2f in ehci_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1376:9 + #20 0x5574ae619cfe in ehci_state_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1942:13 + #21 0x5574ae60e8d9 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2083:21 + #22 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9 + #23 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17 + #24 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5 + #25 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13 + #26 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5 + #27 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5 + #28 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc) + +previously allocated by thread T0 here: + #0 0x5574ae4755b2 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d295b2) + #1 0x7f44ce9e2210 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x56210) + #2 0x5574ae6175be in ehci_state_fetchqtd /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1844:13 + #3 0x5574ae60e7f1 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2073:21 + #4 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9 + #5 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17 + #6 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5 + #7 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13 + #8 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5 + #9 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5 + #10 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc) + +SUMMARY: AddressSanitizer: heap-use-after-free /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:64:28 in usb_packet_unmap +Shadow bytes around the buggy address: + 0x0c2280000820: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2280000830: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2280000840: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd + 0x0c2280000850: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2280000860: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa +=>0x0c2280000870: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd + 0x0c2280000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa + 0x0c2280000890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c22800008a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c22800008b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c22800008c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==797726==ABORTING + +-Alex + +I can still reproduce this issue when compiling the current version of QEMU with Clang + asan. Marking as "Confirmed". + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/541 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/105/KVM/1892966 b/results/classifier/105/KVM/1892966 new file mode 100644 index 00000000..e6f7ee47 --- /dev/null +++ b/results/classifier/105/KVM/1892966 @@ -0,0 +1,202 @@ +KVM: 0.740 +vnc: 0.702 +graphic: 0.693 +mistranslation: 0.679 +other: 0.654 +device: 0.594 +semantic: 0.576 +instruction: 0.562 +boot: 0.521 +network: 0.519 +assembly: 0.503 +socket: 0.479 + +Null-pointer dereference in blk_bs through ide_cancel_dma_sync + +Hello, +Reproducer: +cat << EOF | ./qemu-system-i386 -M pc \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-hd,drive=disk0,bus=ide.1,unit=1 \ +-display none -nodefaults -display none -qtest stdio -accel qtest +outw 0x176 0x35b3 +outb 0x376 0x5f +outb 0x376 0x40 +outl 0xcf8 0x80000904 +outl 0xcfc 0x5c0525b7 +outb 0x176 0x0 +outl 0xcf8 0x8000091e +outl 0xcfc 0xd7580584 +write 0x187 0x1 0x34 +write 0x277 0x1 0x34 +write 0x44f 0x1 0x5c +write 0x53f 0x1 0x5c +write 0x717 0x1 0x34 +write 0x807 0x1 0x34 +write 0x9df 0x1 0x5c +write 0xbb7 0x1 0x34 +write 0xca7 0x1 0x34 +write 0xe7f 0x1 0x5c +write 0xf6f 0x1 0x5c +outb 0xd758 0x5f +outb 0xd758 0x40 +EOF + + +Trace: +[S +0.083320] OK +[R +0.083328] outb 0xd758 0x5f +OK +[S +0.084167] OK +[R +0.084183] outb 0xd758 0x40 +../block/block-backend.c:714:17: runtime error: member access within null pointer of type 'BlockBackend' (aka 'struct BlockBackend') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../block/block-backend.c:714:17 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==843136==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x5593520d8ebc bp 0x7ffc0bb9e0b0 sp 0x7ffc0bb9e010 T0) +==843136==The signal is caused by a READ memory access. +==843136==Hint: address points to the zero page. + #0 0x5593520d8ebc in blk_bs /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:714:12 + #1 0x5593520d2d07 in blk_drain /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:1715:28 + #2 0x55935096e9dc in ide_cancel_dma_sync /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/core.c:723:9 + #3 0x55934f96b9ed in bmdma_cmd_writeb /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/pci.c:298:13 + #4 0x55934fea0547 in bmdma_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/piix.c:75:9 + #5 0x55935175dde0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #6 0x55935175d2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #7 0x55935175af70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #8 0x5593513b98a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #9 0x5593513a2878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #10 0x5593513a23a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #11 0x559351803e07 in cpu_outb /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/ioport.c:60:5 + #12 0x5593516c7b6d in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:392:13 + #13 0x5593516c363e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #14 0x5593516c23e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #15 0x5593527c8762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #16 0x5593527c88aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #17 0x5593527ee514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #18 0x5593526da736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #19 0x7f3be18ef4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #20 0x559352c65c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #21 0x559352c63567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #22 0x559352c62f47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #23 0x55935144108d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #24 0x55934edd351c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #25 0x7f3be10f8cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #26 0x55934ed28cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:714:12 in blk_bs +==843136==ABORTING + +-Alex + +This problem does not trigger anymore for me with the current version of QEMU. Could you please check whether you can still reproduce it somehow with the latest version? + +Probably fixed.. Appears there was some attempt, but I'm not sure if it +ever got merged: +https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg01568.html + +OSS-Fuzz never saw it, so it was probably fixed sometime before November. +-Alex + +On 210527 1434, Thomas Huth wrote: +> This problem does not trigger anymore for me with the current version of +> QEMU. Could you please check whether you can still reproduce it somehow +> with the latest version? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1892966 +> +> Title: +> Null-pointer dereference in blk_bs through ide_cancel_dma_sync +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Hello, +> Reproducer: +> cat << EOF | ./qemu-system-i386 -M pc \ +> -drive file=null-co://,if=none,format=raw,id=disk0 \ +> -device ide-hd,drive=disk0,bus=ide.1,unit=1 \ +> -display none -nodefaults -display none -qtest stdio -accel qtest +> outw 0x176 0x35b3 +> outb 0x376 0x5f +> outb 0x376 0x40 +> outl 0xcf8 0x80000904 +> outl 0xcfc 0x5c0525b7 +> outb 0x176 0x0 +> outl 0xcf8 0x8000091e +> outl 0xcfc 0xd7580584 +> write 0x187 0x1 0x34 +> write 0x277 0x1 0x34 +> write 0x44f 0x1 0x5c +> write 0x53f 0x1 0x5c +> write 0x717 0x1 0x34 +> write 0x807 0x1 0x34 +> write 0x9df 0x1 0x5c +> write 0xbb7 0x1 0x34 +> write 0xca7 0x1 0x34 +> write 0xe7f 0x1 0x5c +> write 0xf6f 0x1 0x5c +> outb 0xd758 0x5f +> outb 0xd758 0x40 +> EOF +> +> +> Trace: +> [S +0.083320] OK +> [R +0.083328] outb 0xd758 0x5f +> OK +> [S +0.084167] OK +> [R +0.084183] outb 0xd758 0x40 +> ../block/block-backend.c:714:17: runtime error: member access within null pointer of type 'BlockBackend' (aka 'struct BlockBackend') +> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../block/block-backend.c:714:17 in +> AddressSanitizer:DEADLYSIGNAL +> ================================================================= +> ==843136==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x5593520d8ebc bp 0x7ffc0bb9e0b0 sp 0x7ffc0bb9e010 T0) +> ==843136==The signal is caused by a READ memory access. +> ==843136==Hint: address points to the zero page. +> #0 0x5593520d8ebc in blk_bs /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:714:12 +> #1 0x5593520d2d07 in blk_drain /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:1715:28 +> #2 0x55935096e9dc in ide_cancel_dma_sync /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/core.c:723:9 +> #3 0x55934f96b9ed in bmdma_cmd_writeb /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/pci.c:298:13 +> #4 0x55934fea0547 in bmdma_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/ide/piix.c:75:9 +> #5 0x55935175dde0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #6 0x55935175d2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #7 0x55935175af70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #8 0x5593513b98a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #9 0x5593513a2878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #10 0x5593513a23a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #11 0x559351803e07 in cpu_outb /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/ioport.c:60:5 +> #12 0x5593516c7b6d in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:392:13 +> #13 0x5593516c363e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 +> #14 0x5593516c23e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 +> #15 0x5593527c8762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 +> #16 0x5593527c88aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 +> #17 0x5593527ee514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 +> #18 0x5593526da736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 +> #19 0x7f3be18ef4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) +> #20 0x559352c65c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 +> #21 0x559352c63567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 +> #22 0x559352c62f47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 +> #23 0x55935144108d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 +> #24 0x55934edd351c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 +> #25 0x7f3be10f8cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +> #26 0x55934ed28cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) +> +> AddressSanitizer can not provide additional info. +> SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/general-fuzz/build/../block/block-backend.c:714:12 in blk_bs +> ==843136==ABORTING +> +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1892966/+subscriptions + + diff --git a/results/classifier/105/KVM/1897783 b/results/classifier/105/KVM/1897783 new file mode 100644 index 00000000..18647b29 --- /dev/null +++ b/results/classifier/105/KVM/1897783 @@ -0,0 +1,169 @@ +KVM: 0.872 +vnc: 0.863 +mistranslation: 0.843 +network: 0.838 +other: 0.833 +device: 0.833 +graphic: 0.826 +assembly: 0.819 +semantic: 0.815 +instruction: 0.814 +socket: 0.791 +boot: 0.762 + +avocado tests not running on aarch64 host + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.1 LTS +Release: 20.04 +Codename: focal + +$ make check-venv + VENV /home/phil/qemu/build/tests/venv + PIP /home/phil/qemu/tests/requirements.txt + ERROR: Command errored out with exit status 1: + command: /home/phil/qemu/build/tests/venv/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"'; __file__='"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ic25ctcg + cwd: /tmp/pip-install-w1h2bh4a/pycdlib/ + Complete output (6 lines): + usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] + or: setup.py --help [cmd1 cmd2 ...] + or: setup.py --help-commands + or: setup.py cmd --help + + error: invalid command 'bdist_wheel' + ---------------------------------------- + ERROR: Failed building wheel for pycdlib +$ + +Eric Auger suggested the fix: 'pip install wheel'. + +Looks like an installation problem. On Ubuntu 20.04, python3-pip depends on python3-wheel: + + +$ apt-cache show python3-pip | grep Depends +Depends: ca-certificates, python3-distutils, python3-setuptools, python3-wheel, python-pip-whl (= 20.0.2-5ubuntu1), python3:any + + +And it gets pulled during an installation attempt: + +$ apt install python3-pip +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following additional packages will be installed: + binutils binutils-aarch64-linux-gnu binutils-common build-essential ca-certificates cpp cpp-9 dirmngr dpkg-dev fakeroot file g++ g++-9 gcc + gcc-9 gcc-9-base gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libalgorithm-diff-perl + libalgorithm-diff-xs-perl libalgorithm-merge-perl libasan5 libasn1-8-heimdal libassuan0 libatomic1 libbinutils libc-dev-bin libc6-dev + libcc1-0 libcrypt-dev libctf-nobfd0 libctf0 libdpkg-perl libexpat1 libexpat1-dev libfakeroot libfile-fcntllock-perl libgcc-9-dev + libgdbm-compat4 libgdbm6 libgomp1 libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal + libisl22 libitm1 libkrb5-26-heimdal libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0 libmagic-mgc libmagic1 libmpc3 + libmpdec2 libmpfr6 libnpth0 libperl5.30 libpython3-dev libpython3-stdlib libpython3.8 libpython3.8-dev libpython3.8-minimal + libpython3.8-stdlib libreadline8 libroken18-heimdal libsasl2-2 libsasl2-modules libsasl2-modules-db libsqlite3-0 libssl1.1 libstdc++-9-dev + libtsan0 libubsan1 libwind0-heimdal linux-libc-dev make manpages manpages-dev mime-support netbase openssl patch perl perl-modules-5.30 + pinentry-curses python-pip-whl python3 python3-dev python3-distutils python3-lib2to3 python3-minimal python3-pkg-resources python3-setuptools + python3-wheel python3.8 python3.8-dev python3.8-minimal readline-common xz-utils zlib1g-dev + +This is on: + +lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.1 LTS +Release: 20.04 +Codename: focal + +This seems to happen on this specific machine, not because it's an aarch64 machine, but because it has python3-minimal installed. The docs on the acceptance test state that: + +--- +Note: the build environment must be using a Python 3 stack, and have +the ``venv`` and ``pip`` packages installed. If necessary, make sure +``configure`` is called with ``--python=`` and that those modules are +available. On Debian and Ubuntu based systems, depending on the +specific version, they may be on packages named ``python3-venv`` and +``python3-pip``. +--- + +As a mitigation, I'm asking the pycdlib maintainer the possibility of also shipping wheels: + +https://github.com/clalancette/pycdlib/issues/53 + +On 10/9/20 10:55 PM, Cleber Rosa wrote: +> On with certain versions of "pip", package installations will attempt +> to create wheels. And, on environments without a "complete" Python +> installation (as described in the acceptance tests requirements docs), +> that will fail. +> +> pycdlib, starting with version 1.11.0, is now being made available +> as wheels, so its instalation on those constrained environments is +> now possible. +> +> Cc: Bug 1897783 <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1880189 + +This BZ is different. The correct URL is: +https://bugs.launchpad.net/qemu/+bug/1897783 + +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Tested-by: Philippe Mathieu-Daudé <email address hidden> + +> Reported-by: Philippe Mathieu-Daudé <email address hidden> +> Signed-off-by: Cleber Rosa <email address hidden> +> --- +> tests/requirements.txt | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/tests/requirements.txt b/tests/requirements.txt +> index 036691c922..a1c631fa59 100644 +> --- a/tests/requirements.txt +> +++ b/tests/requirements.txt +> @@ -2,4 +2,4 @@ +> # in the tests/venv Python virtual environment. For more info, +> # refer to: https://pip.pypa.io/en/stable/user_guide/#id1 +> avocado-framework==81.0 +> -pycdlib==1.9.0 +> +pycdlib==1.11.0 +> + + + +On Fri, Oct 9, 2020 at 5:55 PM Cleber Rosa <email address hidden> wrote: +> +> On with certain versions of "pip", package installations will attempt +> to create wheels. And, on environments without a "complete" Python +> installation (as described in the acceptance tests requirements docs), +> that will fail. +> +> pycdlib, starting with version 1.11.0, is now being made available +> as wheels, so its instalation on those constrained environments is +> now possible. +> +> Cc: Bug 1897783 <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1880189 +> Reported-by: Philippe Mathieu-Daudé <email address hidden> +> Signed-off-by: Cleber Rosa <email address hidden> +> --- +> tests/requirements.txt | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/tests/requirements.txt b/tests/requirements.txt +> index 036691c922..a1c631fa59 100644 +> --- a/tests/requirements.txt +> +++ b/tests/requirements.txt +> @@ -2,4 +2,4 @@ +> # in the tests/venv Python virtual environment. For more info, +> # refer to: https://pip.pypa.io/en/stable/user_guide/#id1 +> avocado-framework==81.0 +> -pycdlib==1.9.0 +> +pycdlib==1.11.0 +> -- +> 2.25.4 +> + +Reviewed-by: Willian Rampazzo <email address hidden> + + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/KVM/1902612 b/results/classifier/105/KVM/1902612 new file mode 100644 index 00000000..9b865687 --- /dev/null +++ b/results/classifier/105/KVM/1902612 @@ -0,0 +1,63 @@ +KVM: 0.742 +mistranslation: 0.718 +vnc: 0.701 +other: 0.697 +graphic: 0.610 +device: 0.570 +boot: 0.553 +semantic: 0.548 +instruction: 0.536 +assembly: 0.529 +network: 0.493 +socket: 0.457 + +assert issue locates in xhci_kick_epctx() in hw/usb/hcd-xhci.c + +Hello, + +I found an assertion failure through hw/usb/hcd-xhci.c. + +This was found in latest version 5.1.0. + +An assertion-failure flaw was found in xhci_kick_epctx() in hw/usb/hcd-xhci.c . XHCI slot's endpoint context is enabled in xhci_configure_slot(), whose ep_ctx structure is controlled by user. With uninitialized endPoint context could trigger assert(ring->dequeue != 0). The guest system could use this flaw to crash the qemu resulting in denial of service. + +To reproduce the assertion failure, please run the QEMU with following command line. + +$ qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic user,model=rtl8139,hostfwd=tcp:0.0.0.0:5555-:22 -device nec-usb-xhci,id=xhci -device usb-tablet,bus=xhci.0,port=1,id=usbdev1 + +The poc is attached. + +Backtrace is as follows: +#0 0x00007f6dfd4c4f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f6dfd4c68b1 in __GI_abort () at abort.c:79 +#2 0x00007f6dfd4b642a in __assert_fail_base (fmt=0x7f6dfd63da38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55e9b9d38a64 "ring->dequeue != 0", file=file@entry=0x55e9b9d388c0 "hw/usb/hcd-xhci.c", line=line@entry=0x7a3, function=function@entry=0x55e9b9d3a5c0 <__PRETTY_FUNCTION__.29754> "xhci_kick_epctx") at assert.c:92 +#3 0x00007f6dfd4b64a2 in __GI___assert_fail (assertion=assertion@entry=0x55e9b9d38a64 "ring->dequeue != 0", file=file@entry=0x55e9b9d388c0 "hw/usb/hcd-xhci.c", line=line@entry=0x7a3, function=function@entry=0x55e9b9d3a5c0 <__PRETTY_FUNCTION__.29754> "xhci_kick_epctx") at assert.c:101 +#4 0x000055e9b9a3292f in xhci_kick_epctx (epctx=0x7f6da836b510, streamid=streamid@entry=0x0) at hw/usb/hcd-xhci.c:1955 +#5 0x000055e9b9a3c64b in xhci_kick_ep (streamid=0x0, epid=0x1, slotid=0x11, xhci=0x7f6df8b38010) at hw/usb/hcd-xhci.c:1861 +#6 0x000055e9b9a3c64b in xhci_doorbell_write (ptr=0x7f6df8b38010, reg=0x11, val=0x1, size=<optimized out>) at hw/usb/hcd-xhci.c:3162 +#7 0x000055e9b977d274 in memory_region_write_accessor (mr=0x7f6df8b38d80, addr=0x44, value=<optimized out>, size=0x1, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:483 +#8 0x000055e9b977ad86 in access_with_adjusted_size (addr=addr@entry=0x44, value=value@entry=0x7f6dfb915f88, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55e9b977d1f0 <memory_region_write_accessor>, mr=0x7f6df8b38d80, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:544 +#9 0x000055e9b977f4c8 in memory_region_dispatch_write (mr=mr@entry=0x7f6df8b38d80, addr=0x44, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:1483 +#10 0x000055e9b972c691 in flatview_write_continue (fv=fv@entry=0x7f6da951f750, addr=addr@entry=0xfebf2044, attrs=..., ptr=ptr@entry=0x7f6dfb9160e0, len=len@entry=0x1, addr1=<optimized out>, l=<optimized out>, mr=0x7f6df8b38d80) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/exec.c:3137 +#11 0x000055e9b972c826 in flatview_write (fv=0x7f6da951f750, addr=0xfebf2044, attrs=..., buf=buf@entry=0x7f6dfb9160e0, len=0x1) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/exec.c:3177 +#12 0x000055e9b972c89a in subpage_write (opaque=<optimized out>, addr=<optimized out>, value=<optimized out>, len=<optimized out>, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/exec.c:2789 +#13 0x000055e9b977b269 in memory_region_write_with_attrs_accessor (mr=0x7f6da9534650, addr=0x44, value=<optimized out>, size=0x1, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:503 +#14 0x000055e9b977ad86 in access_with_adjusted_size (addr=addr@entry=0x44, value=value@entry=0x7f6dfb9161f8, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55e9b977b1e0 <memory_region_write_with_attrs_accessor>, mr=0x7f6da9534650, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:544 +#15 0x000055e9b977f4c8 in memory_region_dispatch_write (mr=0x7f6da9534650, addr=addr@entry=0x44, data=<optimized out>, data@entry=0x1, op=op@entry=MO_8, attrs=...) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/memory.c:1483 +#16 0x000055e9b979021f in io_writex (env=env@entry=0x55e9baed5b50, iotlbentry=iotlbentry@entry=0x7f6da8b8bc10, mmu_idx=mmu_idx@entry=0x1, val=val@entry=0x1, addr=addr@entry=0x7fbba0601044, retaddr=retaddr@entry=0x7f6db9d90d48, op=MO_8) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cputlb.c:1084 +#17 0x000055e9b9794c42 in store_helper (op=MO_8, retaddr=0x7f6db9d90d48, oi=<optimized out>, val=<optimized out>, addr=0x7fbba0601044, env=0x55e9baed5b50) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cputlb.c:1954 +#18 0x000055e9b9794c42 in helper_ret_stb_mmu (env=0x55e9baed5b50, addr=0x7fbba0601044, val=0x1, oi=<optimized out>, retaddr=0x7f6db9d90d48) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cputlb.c:2056 +#19 0x00007f6db9d90d48 in code_gen_buffer () +#20 0x000055e9b97a5217 in cpu_tb_exec (itb=<optimized out>, cpu=0x7f6db9d240c0 <code_gen_buffer+97665171>) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cpu-exec.c:172 +#21 0x000055e9b97a5217 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7f6db9d240c0 <code_gen_buffer+97665171>) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cpu-exec.c:619 +#22 0x000055e9b97a5217 in cpu_exec (cpu=cpu@entry=0x55e9baecd2f0) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/accel/tcg/cpu-exec.c:732 +#23 0x000055e9b976ff9f in tcg_cpu_exec (cpu=0x55e9baecd2f0) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/cpus.c:1405 +#24 0x000055e9b97723cb in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x55e9baecd2f0) at /home/zjusvn/qemu5-hypervisor/qemu-5.0.0/cpus.c:1713 +#25 0x000055e9b9be7d66 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:519 +#26 0x00007f6dfd87e6db in start_thread (arg=0x7f6dfb917700) at pthread_create.c:463 +#27 0x00007f6dfd5a7a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + + +This looks like a duplicate of https://bugs.launchpad.net/qemu/+bug/1883732 + diff --git a/results/classifier/105/KVM/1906 b/results/classifier/105/KVM/1906 new file mode 100644 index 00000000..2c3f4077 --- /dev/null +++ b/results/classifier/105/KVM/1906 @@ -0,0 +1,47 @@ +KVM: 0.631 +vnc: 0.589 +mistranslation: 0.588 +graphic: 0.542 +instruction: 0.534 +device: 0.518 +network: 0.513 +socket: 0.508 +other: 0.484 +assembly: 0.476 +semantic: 0.475 +boot: 0.452 + +Failed to compile QEMU 7.0.0 source code. recipe for target 'run-ninja' failed. +Description of problem: +Failed to compiling the download QEMU 7.0.0 source code. It seems to be due to something wrong with ninja. +The followings are error logs after executing command "make -j$(nproc)": + +changing dir to build for make ""... +make[1]: Entering directory '/home/liangke/os-env/qemu-7.0.0/build' +/usr/bin/ninja build.ninja && touch build.ninja.stamp +**ninja: no work to do.** +... +... +... +[1350/2396] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o +**FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o** +cc -m64 -mcx16 -Ilibqemu-riscv64-softmmu.fa.p -I. -I.. -Itarget/riscv -I../target/riscv -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/liangke/os-env/qemu-7.0.0/linux-headers -isystem linux-headers -iquote . -iquote /home/liangke/os-env/qemu-7.0.0 -iquote /home/liangke/os-env/qemu-7.0.0/include -iquote /home/liangke/os-env/qemu-7.0.0/disas/libvixl -iquote /home/liangke/os-env/qemu-7.0.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -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 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="riscv64-softmmu-config-target.h"' '-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -MF libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o.d -o libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -c ../target/riscv/translate.c +**cc: fatal error: Killed signal terminated program cc1** +**compilation terminated.** +**ninja: build stopped: subcommand failed.** +**Makefile:163: recipe for target 'run-ninja' failed** +**make[1]: *** [run-ninja] Error 1** +make[1]: Leaving directory '/home/liangke/os-env/qemu-7.0.0/build' +**GNUmakefile:10: recipe for target 'all' failed** +**make: *** [all] Error 2** +Steps to reproduce: +1. cd qemu-7.0.0 source code folder; +2. ./configure --target-list=riscv64-softmmu,riscv64-linux-user; +3. make -j$(nproc) +Additional information: +1. I downloaded the source code from https://download.qemu.org/qemu-7.0.0.tar.xz. +2. my compiling prerequisites: +sudo apt install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev \ + gawk build-essential bison flex texinfo gperf libtool patchutils bc ninja-build \ + zlib1g-dev libexpat-dev pkg-config libglib2.0-dev libpixman-1-dev git tmux python3 +3. Found ninja-1.8.2 at /usr/bin/ninja diff --git a/results/classifier/105/KVM/1908513 b/results/classifier/105/KVM/1908513 new file mode 100644 index 00000000..d637a834 --- /dev/null +++ b/results/classifier/105/KVM/1908513 @@ -0,0 +1,81 @@ +KVM: 0.865 +vnc: 0.847 +other: 0.825 +graphic: 0.784 +instruction: 0.765 +device: 0.759 +mistranslation: 0.756 +semantic: 0.741 +assembly: 0.732 +boot: 0.727 +socket: 0.724 +network: 0.706 + +assertion failure in mptsas1068 emulator + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through mptsas1068 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/mptsas.c:968: void mptsas_interrupt_status_write(MPTSASState *): Assertion +`s->intr_status & MPI_HIS_DOORBELL_INTERRUPT' failed. +[1] 16951 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-5.2/build/qemu-system-i386 -m 512 -drive + +Program terminated with signal SIGABRT, Aborted. +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fc7d6023700 (LWP 23475))] +gdb-peda$ bt +#0 0x00007fc7efa13f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fc7efa158b1 in __GI_abort () at abort.c:79 +#2 0x00007fc7efa0542a in __assert_fail_base (fmt=0x7fc7efb8ca38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x56439214d593 "s->intr_status & MPI_HIS_DOORBELL_INTERRUPT", file=file@entry=0x56439214d4a7 "../hw/scsi/mptsas.c", line=line@entry=0x3c8, function=function@entry=0x56439214d81c "void mptsas_interrupt_status_write(MPTSASState *)") at assert.c:92 +#3 0x00007fc7efa054a2 in __GI___assert_fail (assertion=0x56439214d593 "s->intr_status & MPI_HIS_DOORBELL_INTERRUPT", file=0x56439214d4a7 "../hw/scsi/mptsas.c", line=0x3c8, function=0x56439214d81c "void mptsas_interrupt_status_write(MPTSASState *)") at assert.c:101 +#4 0x0000564391a43963 in mptsas_interrupt_status_write (s=<optimized out>) at ../hw/scsi/mptsas.c:968 +#5 0x0000564391a43963 in mptsas_mmio_write (opaque=0x5643943dd5b0, addr=0x30, val=0x18000000, size=<optimized out>) at ../hw/scsi/mptsas.c:1052 +#6 0x0000564391e08798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#7 0x0000564391e0858e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#8 0x0000564391e0858e in memory_region_dispatch_write (mr=0x5643943ddea0, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#9 0x0000564391eff228 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=<optimized out>, env=<optimized out>) + at ../accel/tcg/cputlb.c:1378 +#10 0x0000564391eff228 in store_helper (env=<optimized out>, addr=<optimized out>, val=<optimized out>, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2397 +#11 0x0000564391eff228 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x2, oi=<optimized out>, retaddr=0x7fc78841b401) at ../accel/tcg/cputlb.c:2463 +#12 0x00007fc78841b401 in code_gen_buffer () +#13 0x0000564391dd0da0 in cpu_tb_exec (cpu=0x56439363e650, itb=<optimized out>) at ../accel/tcg/cpu-exec.c:178 +#14 0x0000564391dd19eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#15 0x0000564391dd19eb in cpu_exec (cpu=0x56439363e650) at ../accel/tcg/cpu-exec.c:771 +#16 0x0000564391e00b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#17 0x0000564391e00b9f in tcg_cpu_thread_fn (arg=0x56439363e650) at ../accel/tcg/tcg-cpus.c:427 +#18 0x00005643920d8775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#19 0x00007fc7efdcd6db in start_thread (arg=0x7fc7d6023700) at pthread_create.c:463 + +To reproduce this issue, please run the QEMU with the following command line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line. +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device mptsas1068,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + +This still triggers with the current version from git master, marking as Confirmed + + +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/304 + + diff --git a/results/classifier/105/KVM/1908832 b/results/classifier/105/KVM/1908832 new file mode 100644 index 00000000..170365c1 --- /dev/null +++ b/results/classifier/105/KVM/1908832 @@ -0,0 +1,267 @@ +KVM: 0.490 +instruction: 0.473 +semantic: 0.442 +assembly: 0.427 +other: 0.420 +vnc: 0.409 +device: 0.396 +mistranslation: 0.366 +graphic: 0.358 +network: 0.323 +boot: 0.293 +socket: 0.184 + +jack audio dev produces no sound + +Hi, + +I'm testing the new jack audiodev backend in my +laptop. The host system is gentoo, using the +ebuild for qemu 5.1.0-r2, and I'm using jack +use flag globally in the system so any ebuild +that have support for jack should be build with +it. The jack setup reportedly works as I use it +with firefox, and mumble with no trouble. When +I launch the following script, I see the vm +connects to jack: + +/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \ + -cpu host -smp 2,cores=2,threads=1 \ + -m 4G -L /usr/share/qemu \ + -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ + -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \ + -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent \ + -device nec-usb-xhci,id=usb \ + -device usb-host,vendorid=0x04ca,productid=0x708e \ + -device usb-host,vendorid=0x1050,productid=0x0407 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev1 \ + -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev2 \ + -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev3 \ + -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio + +Output of vm initialization: + +jack: JACK output configured for 48000Hz (1024 samples) +jack: JACK input configured for 48000Hz (1024 samples) +gl_version 46 - core profile enabled +GLSL feature level 430 + +Though executing any application that uses sound, +for instance, any youtube video through browser, +I listen nothing. By executing pkill jackd, and +launching the same script replacing the audiodev +line for the following: + + -audiodev id=alsa,driver=alsa -device ich9-intel-hda -device hda-duplex,audiodev=alsa \ + +The audio works, and I can listen to music, or +any other kind of application, though I cannot +listen anything else in the host. + +The guest is a simple debian testing(bullseye) +system with plasma desktop, using pulseaudio, +nothing fancy. + +Thanks! + +José + +Does this patch make a difference for you? +https://github.com/qemu/qemu/commit/a6e037390dd91276f4a631d41188c87e8a60bb3f + +If not, what's the precise JACK version you are using. + +I'm afraid it didn't. Jack version is: + +* media-sound/jack2 + Latest version available: 1.9.16 + Latest version installed: 1.9.16 + Size of files: 952 KiB + Homepage: https://jackaudio.org/ + Description: Jackdmp jack implemention for multi-processor machine + License: GPL-2 + +qemu config used in build: + +../configure --prefix=/usr --sysconfdir=/etc --bindir=/usr/bin --libdir=/usr/lib64 --datadir=/usr/share --docdir=/usr/share/doc/qemu-5.1.0-r2/html --mandir=/usr/share/man --with-confsuffix=/qemu --localstatedir=/var --disable-bsd-user --disable-containers --disable-guest-agent --disable-strip --disable-tcg-interpreter --disable-werror --disable-gcrypt --python=/usr/bin/python3.8 --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --host-cc=x86_64-pc-linux-gnu-gcc --disable-debug-info --disable-debug-tcg --disable-docs --disable-plugins --enable-attr --disable-brlapi --enable-linux-aio --enable-bzip2 --disable-capstone --enable-cap-ng --enable-curl --enable-fdt --disable-glusterfs --disable-gnutls --disable-nettle --enable-gtk --disable-rdma --disable-libiscsi --enable-linux-io-uring --disable-jemalloc --enable-vnc-jpeg --enable-kvm --disable-lzo --disable-mpath --enable-curses --disable-libnfs --disable-numa --enable-opengl --enable-vnc-png --disable-rbd --disable-vnc-sasl --enable-sdl --disable-sdl-image --enable-seccomp --enable-slirp=system --disable-smartcard --disable-snappy --enable-spice --disable-libssh --enable-libusb --enable-usb-redir --disable-vde --enable-vhost-net --disable-vhost-user-fs --enable-virglrenderer --disable-virtfs --enable-vnc --disable-vte --disable-xen --disable-xen-pci-passthrough --disable-xfsctl --enable-xkbcommon --disable-zstd --enable-libxml2 --audio-drv-list=jack,sdl,alsa,oss, --disable-linux-user --enable-system --disable-tools --target-list=aarch64-softmmu,arm-softmmu,riscv32-softmmu,riscv64-softmmu,x86_64-softmmu --enable-pie + +thanks! + +José. + +I unmasked qemu-5.2.0-r1, well, actually any newer qemu coming +from gentoo, and rebuild the software. The situation is still +reproducible, which confirms what I tested yesterday with the +patch. I also cleaned up the launch script to remove several +spice related unneeded since I use the gtk display, here is +how it looks like right now: + +/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \ + -cpu host -smp 4,cores=4,threads=1 \ + -m 2G -L /usr/share/qemu \ + -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ + -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \ + -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \ + -device nec-usb-xhci,id=usb \ + -device usb-host,vendorid=0x04ca,productid=0x708e \ + -device usb-host,vendorid=0x1050,productid=0x0407 \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio + +Thanks! + +José. + +Hi, + +I spend some time debugging this during the morning, I found that there is a check +while connecting the ports that always exits the function without connecting the +jack ports, simplifying it as in the following diff lets me build and use the +audio outputs correctly in the vm: + +diff --git a/audio/jackaudio.c b/audio/jackaudio.c +index 3b7c18443d..f417e4db8a 100644 +--- a/audio/jackaudio.c ++++ b/audio/jackaudio.c +@@ -369,7 +369,7 @@ static size_t qjack_read(HWVoiceIn *hw, void *buf, size_t len) + + static void qjack_client_connect_ports(QJackClient *c) + { +- if (!c->connect_ports || !c->opt->connect_ports) { ++ if (!c->connect_ports) { + return; + } + +So, I wonder, what is this c->opt->connect_ports all about, is it needed, or just +wrongly initialized so that it caps the port connection? + +Thanks! + +Jose. + +just for completeness, this is how the output of the vm launch +looks like after the change: + +jack: connect out-(null):output 0 -> system:playback_1 +jack: connect out-(null):output 1 -> system:playback_2 +jack: JACK output configured for 48000Hz (1024 samples) +jack: connect system:capture_1 -> in-(null):input 0 +jack: connect system:capture_2 -> in-(null):input 1 +jack: JACK input configured for 48000Hz (1024 samples) +gl_version 46 - core profile enabled +GLSL feature level 430 + +And both input and output works as expected. + +Best regards. + +Jose. + +c->opt->connect_ports is an optional user supplied configuration argument which allows the user to specify a regular expression pattern which is used by QEMU's JACK audio driver to automatically connect its JACK ports to. From qapi/audio.json: + +## +# @AudiodevJackPerDirectionOptions: +# +# Options of the JACK backend that are used for both playback and +# recording. +# +# @server-name: select from among several possible concurrent server instances +# (default: environment variable $JACK_DEFAULT_SERVER if set, else "default") +# +# @client-name: the client name to use. The server will modify this name to +# create a unique variant, if needed unless @exact-name is true (default: the +# guest's name) +# +# @connect-ports: if set, a regular expression of JACK client port name(s) to +# monitor for and automatically connect to +# +# @start-server: start a jack server process if one is not already present +# (default: false) +# +# @exact-name: use the exact name requested otherwise JACK automatically +# generates a unique one, if needed (default: false) +# +# Since: 5.1 +## +{ 'struct': 'AudiodevJackPerDirectionOptions', + 'base': 'AudiodevPerDirectionOptions', + 'data': { + '*server-name': 'str', + '*client-name': 'str', + '*connect-ports': 'str', + '*start-server': 'bool', + '*exact-name': 'bool' } } + +I agree with you that it would be more user friendly to auto connect QEMU's output ports to system:playback_1, system:playback_2 and QEMU's input ports to system:capture_1, system:capture_2 respectively if the user did not specify any argument for "connect-ports". + +However I think your patch is a bit too simple, i.e. it is more or less luck that the system ports end up as the first two members in the lookup array "ports". It is working right now, but there is no guarantee about the order of the ports returned by jack_get_ports(): + +https://jackaudio.org/api/group__PortSearching.html + +So I would suggest changing your patch a bit by passing a lookup pattern like "system:playback_.*" to jack_get_ports() for QEMU output ports and a pattern like "system:capture_.*" for QEMU input ports, if c->opt->connect_ports is empty that is. + +Would you try to send a patch like this? And if yes, would you mind sending your patch directly to the qemu-devel mailing list? That would allow us to merge your patch more efficiently & quickly. + +https://wiki.qemu.org/Contribute/SubmitAPatch + +Yes, I agree, the patch itself is a quick fix, indeed, if I look to +the graphs in QJackCtl, I would expect to see new bubbles from qemu +connected to the system ports, as it happens when I connect Firefox +or Falkon through alsa -> jack plugin, as per the output you can +see it's using some sort of null sink already populated. + +About the patch, yes no problem I'll modify it and submit. + +Thanks! + +Jose. + +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. + + +Just for the records: the proposed patch was discussed on the QEMU mailing list, but there was no final consensus (yet) to accept the patch. Full discussion: + +https://<email address hidden>/msg785555.html + +It's probably Ok to let this report expire for now. If there are more users complaining about the current design of expecting the user to connect QEMU's JACK ports, then we can still go ahead with the patch. + +Ticket has been moved here (thanks, José!): +https://gitlab.com/qemu-project/qemu/-/issues/278 +... thus closing this on Launchpad now. + diff --git a/results/classifier/105/KVM/1910941 b/results/classifier/105/KVM/1910941 new file mode 100644 index 00000000..08cc0e05 --- /dev/null +++ b/results/classifier/105/KVM/1910941 @@ -0,0 +1,143 @@ +KVM: 0.763 +other: 0.722 +vnc: 0.689 +mistranslation: 0.642 +graphic: 0.591 +device: 0.583 +semantic: 0.567 +instruction: 0.563 +network: 0.533 +socket: 0.520 +assembly: 0.513 +boot: 0.483 + +Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through virtio-blk emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + +``` + +qemu-system-i386: /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +[1] 1877 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-master/build/i386-softmmu/qemu-system-i386 + +Program terminated with signal SIGABRT, Aborted. +#0 0x00007f71cc171f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f71cc1738b1 in __GI_abort () at abort.c:79 +#2 0x00007f71cc16342a in __assert_fail_base (fmt=0x7f71cc2eaa38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=file@entry=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=line@entry=0x58, function=function@entry=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:92 +#3 0x00007f71cc1634a2 in __GI___assert_fail (assertion=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=0x58, function=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:101 +#4 0x000056537af3c917 in address_space_stw_le_cached (attrs=..., result=<optimized out>, cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88 +#5 0x000056537af3c917 in stw_le_phys_cached (cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_phys.h.inc:121 +#6 0x000056537af3c917 in virtio_stw_phys_cached (vdev=<optimized out>, cache=<optimized out>, pa=<optimized out>, value=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/hw/virtio/virtio-access.h:196 +#7 0x000056537af2b809 in vring_set_avail_event (vq=<optimized out>, val=0x0) at ../hw/virtio/virtio.c:429 +#8 0x000056537af2b809 in virtio_queue_split_set_notification (vq=<optimized out>, enable=<optimized out>) at ../hw/virtio/virtio.c:438 +#9 0x000056537af2b809 in virtio_queue_set_notification (vq=<optimized out>, enable=0x1) at ../hw/virtio/virtio.c:499 +#10 0x000056537b07ce1c in virtio_blk_handle_vq (s=0x56537d6bb3a0, vq=0x56537d6c0680) at ../hw/block/virtio-blk.c:795 +#11 0x000056537af3eb4d in virtio_queue_notify_aio_vq (vq=0x56537d6c0680) at ../hw/virtio/virtio.c:2326 +#12 0x000056537af3ba04 in virtio_queue_host_notifier_aio_read (n=<optimized out>) at ../hw/virtio/virtio.c:3533 +#13 0x000056537b20901c in aio_dispatch_handler (ctx=0x56537c4179f0, node=0x7f71a810b370) at ../util/aio-posix.c:329 +#14 0x000056537b20838c in aio_dispatch_handlers (ctx=<optimized out>) at ../util/aio-posix.c:372 +#15 0x000056537b20838c in aio_dispatch (ctx=0x56537c4179f0) at ../util/aio-posix.c:382 +#16 0x000056537b1f99cb in aio_ctx_dispatch (source=0x2, callback=0x7ffc8add9f90, user_data=0x0) at ../util/async.c:306 +#17 0x00007f71d1c10417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#18 0x000056537b1f1bab in glib_pollfds_poll () at ../util/main-loop.c:232 +#19 0x000056537b1f1bab in os_host_main_loop_wait (timeout=<optimized out>) at ../util/main-loop.c:255 +#20 0x000056537b1f1bab in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531 +#21 0x000056537af879d7 in qemu_main_loop () at ../softmmu/runstate.c:720 +#22 0x000056537a928a3b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, argv@entry=0x7ffc8adda718, envp=<optimized out>) at ../softmmu/main.c:50 +#23 0x00007f71cc154b97 in __libc_start_main (main=0x56537a928a30 <main>, argc=0x15, argv=0x7ffc8adda718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc8adda708) at ../csu/libc-start.c:310 +#24 0x000056537a92894a in _start () + +``` + +To reproduce this issue, please run the QEMU with the following command line. + +``` + +# To reproduce this issue, please run the QEMU process with the following command line. + +$ qemu-system-i386 -m 512 -drive file=hyfuzz.img,index=0,media=disk,format=raw -device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 -drive file=disk.img,if=none,id=drive0 + +``` + +Please let me know if I can provide any further info. + +Thank you. + + + +This is OSS-Fuzz Issue 26797 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw \ +-serial none -monitor none -qtest stdio -nographic +outl 0xcf8 0x80001890 +outl 0xcfc 0x4 +outl 0xcf8 0x8000188a +outl 0xcfc 0xd4624 +outl 0xcf8 0x80001894 +outl 0xcfc 0x20000002 +outl 0xcf8 0x80001889 +outl 0xcfc 0x18000000 +outl 0xcf8 0x80001896 +outl 0xcfc 0x0 +outl 0xcf8 0x8000188c +outw 0xcfc 0x20 +outl 0xcf8 0x80001894 +outl 0xcfc 0x1 +outl 0xcf8 0x8000188c +outw 0xcfc 0x1c +outl 0xcf8 0x80001895 +outl 0xcfc 0x0 +outl 0xcf8 0x80001889 +outl 0xcfc 0x18000000 +outl 0xcf8 0x80001894 +outl 0xcfc 0x40 +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001894 +outl 0xcfc 0x1004 +EOF + +=== Stack Trace === +qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + +==2382430== ERROR: libFuzzer: deadly signal +#8 address_space_stw_le_cached /src/qemu/include/exec/memory_ldst_cached.h.inc:88:5 +#9 stw_le_phys_cached /src/qemu/include/exec/memory_ldst_phys.h.inc:121:5 +#10 virtio_stw_phys_cached /src/qemu/include/hw/virtio/virtio-access.h:196:9 +#11 vring_set_avail_event /src/qemu/hw/virtio/virtio.c:429:5 +#12 virtio_queue_split_set_notification /src/qemu/hw/virtio/virtio.c:438:9 +#13 virtio_queue_set_notification /src/qemu/hw/virtio/virtio.c:499:9 +#14 virtio_blk_handle_vq /src/qemu/hw/block/virtio-blk.c:795:13 +#15 virtio_blk_data_plane_handle_output /src/qemu/hw/block/dataplane/virtio-blk.c:165:12 +#16 virtio_queue_notify_aio_vq /src/qemu/hw/virtio/virtio.c:2326:15 +#17 virtio_queue_host_notifier_aio_read /src/qemu/hw/virtio/virtio.c:3533:9 +#18 aio_dispatch_handler /src/qemu/util/aio-posix.c:329:9 +#19 aio_dispatch_handlers /src/qemu/util/aio-posix.c:372:20 +#20 aio_dispatch /src/qemu/util/aio-posix.c:382:5 +#21 aio_ctx_dispatch /src/qemu/util/async.c:306:5 +#22 g_main_context_dispatch +#23 glib_pollfds_poll /src/qemu/util/main-loop.c:232:9 +#24 os_host_main_loop_wait /src/qemu/util/main-loop.c:255:5 +#25 main_loop_wait /src/qemu/util/main-loop.c:531:11 +#26 flush_events /src/qemu/tests/qtest/fuzz/fuzz.c:49:9 +#27 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:683:17 + +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.6797 + + +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/301 + + diff --git a/results/classifier/105/KVM/1912224 b/results/classifier/105/KVM/1912224 new file mode 100644 index 00000000..291f73eb --- /dev/null +++ b/results/classifier/105/KVM/1912224 @@ -0,0 +1,384 @@ +KVM: 0.761 +device: 0.746 +other: 0.728 +instruction: 0.711 +vnc: 0.706 +semantic: 0.703 +network: 0.693 +graphic: 0.692 +boot: 0.691 +assembly: 0.682 +socket: 0.677 +mistranslation: 0.671 + +qemu may freeze during drive-mirroring on fragmented FS + + +We have odd behavior in operation where qemu freeze during long +seconds, We started an thread about that issue here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05623.html + +It happens at least during openstack nova snapshot (qemu blockdev-mirror) +or live block migration(which include network copy of disk). + +After further troubleshoots, it seems related to FS fragmentation on host. + +reproducible at least on: +Ubuntu 18.04.3/4.18.0-25-generic/qemu-4.0 +Ubuntu 16.04.6/5.10.6/qemu-5.2.0-rc2 + +# Lets create a dedicated file system on a SSD/Nvme 60GB disk in my case: +$sudo mkfs.ext4 /dev/sda3 +$sudo mount /dev/sda3 /mnt +$df -h /mnt +Filesystem Size Used Avail Use% Mounted on +/dev/sda3 59G 53M 56G 1% /mnt + +#Create a fragmented disk on it using 2MB Chunks (about 30min): +$sudo python3 create_fragged_disk.py /mnt 2 +Filling up FS by Creating chunks files in: /mnt/chunks +We are probably full as expected!!: [Errno 28] No space left on device +Creating fragged disk file: /mnt/disk + +$ls -lhs +59G -rw-r--r-- 1 root root 59G Jan 15 14:08 /mnt/disk + +$ sudo e4defrag -c /mnt/disk + Total/best extents 41971/30 + Average size per extent 1466 KB + Fragmentation score 2 + [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag] + This file (/mnt/disk) does not need defragmentation. + Done. + +# the tool^^^ says it is not enough fragmented to be able to defrag. + +#Inject an image on fragmented disk +sudo chown ubuntu /mnt/disk +wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img +qemu-img convert -O raw bionic-server-cloudimg-amd64.img \ + bionic-server-cloudimg-amd64.img.raw +dd conv=notrunc iflag=fullblock if=bionic-server-cloudimg-amd64.img.raw \ + of=/mnt/disk bs=1M +virt-customize -a /mnt/disk --root-password password:xxxx + +# logon run console activity ex: ping -i 0.3 127.0.0.1 +$qemu-system-x86_64 -m 2G -enable-kvm -nographic \ + -chardev socket,id=test,path=/tmp/qmp-monitor,server,nowait \ + -mon chardev=test,mode=control \ + -drive file=/mnt/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none,discard\ + -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on + +$sync +$echo 3 | sudo tee -a /proc/sys/vm/drop_caches + +#start drive-mirror via qmp on another SSD/nvme partition +nc -U /tmp/qmp-monitor +{"execute":"qmp_capabilities"} +{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","target":"/home/ubuntu/mirror","sync":"full","format":"qcow2"}} +^^^ qemu console may start to freeze at this step. + +NOTE: + - smaller chunk sz and bigger disk size the worst it is. + In operation we also have issue on 400GB disk size with average 13MB/extent + - Reproducible also on xfs + + +Expected behavior: +------------------- +QEMU should remain steady, eventually only have decrease storage Performance +or mirroring, because of fragmented fs. + +Observed behavior: +------------------- +Perf of mirroring is still quite good even on fragmented FS, +but it breaks qemu. + + +###################### create_fragged_disk.py ############ +import sys +import os +import tempfile +import glob +import errno + +MNT_DIR = sys.argv[1] +CHUNK_SZ_MB = int(sys.argv[2]) +CHUNKS_DIR = MNT_DIR + '/chunks' +DISK_FILE = MNT_DIR + '/disk' + +if not os.path.exists(CHUNKS_DIR): + os.makedirs(CHUNKS_DIR) + +with open("/dev/urandom", "rb") as f_rand: + mb_rand=f_rand.read(1024 * 1024) + +print("Filling up FS by Creating chunks files in: ",CHUNKS_DIR) +try: + while True: + tp = tempfile.NamedTemporaryFile(dir=CHUNKS_DIR,delete=False) + for x in range(CHUNK_SZ_MB): + tp.write(mb_rand) + os.fsync(tp) + tp.close() +except Exception as ex: + print("We are probably full as expected!!: ",ex) + +chunks = glob.glob(CHUNKS_DIR + '/*') + +print("Creating fragged disk file: ",DISK_FILE) +with open(DISK_FILE, "w+b") as f_disk: + for chunk in chunks: + try: + os.unlink(chunk) + for x in range(CHUNK_SZ_MB): + f_disk.write(mb_rand) + os.fsync(f_disk) + except IOError as ex: + if ex.errno != errno.ENOSPC: + raise +###########################################################3 + + +Seems a regression introduce in commit : (2.7.0) + +commit 0965a41e998ab820b5d660c8abfc8c819c97bc1b +Author: Vladimir Sementsov-Ogievskiy <email address hidden> +Date: Thu Jul 14 20:19:01 2016 +0300 + + mirror: double performance of the bulk stage if the disc is full + + Mirror can do up to 16 in-flight requests, but actually on full copy + (the whole source disk is non-zero) in-flight is always 1. This happens + as the request is not limited in size: the data occupies maximum available + capacity of s->buf. + + The patch limits the size of the request to some artificial constant + (1 Mb here), which is not that big or small. This effectively enables + back parallelism in mirror code as it was designed. + + The result is important: the time to migrate 10 Gb disk is reduced from + ~350 sec to 170 sec. + +If I revert this commit on master on top of (fef80ea073c48) (minor conflicts) issue disappears. + +on a fragmented file (average size per exent 2125 KB) of 58GB: +upstream 207s (285 MB/s) instance is broken during mirroring +upstream with revert 225s (262 MB/s) instance is fine. + +not fully tested, but the patch probably improve perf in other cases +(as disccuss in git message), maybe just need to improve to avoid the freeze? + +Another test that confirm the perf drop after the revert, + +live-migration of disk of 51GB (raw written data, without hole) +between two host with nvme disk, 10Gb/s connectivity: + +master qemu 1m14s (737 MB/s) +master qemu with reverted patch 2m30s (353 MB/s) + +I think the issue come from SEEK_HOLE call. +SEEK_HOLE is fine until we find a hole close to the offset, +It becomes a very expensive call when the HOLE is at the +end of file of a big file (or smaller fragmented file +because there is a lot of FS extent the driver should check.) + +When we run a mirror on a 400GB raw file fully written (not fragmented): +for each 1MB chunk we do: + mirror_iteration(MirrorBlockJob *s) + -> bdrv_block_status_above(..) + ... -> find_allocation (file-posix.c) + -> offs = lseek(s->fd, start, SEEK_HOLE); + +In strace this result like this: +[pid 105339] 17:41:05.548334 lseek(38, 0, SEEK_HOLE) = 429496729600 <0.015172> +[pid 105339] 17:41:05.564798 lseek(38, 1048576, SEEK_HOLE) = 429496729600 <0.008762> +[pid 105339] 17:41:05.576223 lseek(38, 2097152, SEEK_HOLE) = 429496729600 <0.006250> +[pid 105339] 17:41:05.583299 lseek(38, 3145728, SEEK_HOLE) = 429496729600 <0.005511> +[pid 105339] 17:41:05.589771 lseek(38, 4194304, SEEK_HOLE) = 429496729600 <0.005181> +[pid 105339] 17:41:05.596390 lseek(38, 5242880, SEEK_HOLE) = 429496729600 <0.005829> +[pid 105339] 17:41:05.603473 lseek(38, 6291456, SEEK_HOLE) = 429496729600 <0.005276> +[pid 105339] 17:41:05.609833 lseek(38, 7340032, SEEK_HOLE) = 429496729600 <0.006089> + +^^ for each MB FS driver is going accross all file extent till the end of the file, + the qemu unstability comes from that. + +Maybe one way to fix that is to not run SEEK_HOLE at each iteration +but run it only when needed. +Some thing like adding a property in MirrorBlockJob like hole_offest, +that store where is the last known offset where there is a hole. +And pass it on find_allocation and evaluate the need +to run SEEK_HOLE or not. + +Like this: +typedef struct MirrorBlockJob { +... + int64_t hole_offset; /* last known hole_offset during migration */ +} + +mirror_iteration(MirrorBlockJob *s) + -> bdrv_block_status_above(...., &s->hole_offset) + ... + -> find_allocation (...., hole_offest) + evaluate offset and hole_offest to run or not SEEK_HOLE. + +Note this involve adding an additional arg to bdrv_block_status_above(), and we need to update +code for all driver. + +Is there a better way to fix that issue ? + + +Hi, + +As I said on IRC, I’m not sure this additional block_status argument would be good, because the hole offset needs to be reset when the file is written to (at least on zero writes; if we additionally stored a data offset, then that would need to be reset on all writes). Technically, mirror can do that, because all writes should go through it, but it doesn’t seem the right place to cache it there. Furthermore, depending on how often writes occur, this cache may end up not doing much. + +We could place it in file-posix instead (i.e., it would store the last offset where SEEK_HOLE/DATA was invoked and the last offset that they returned, so if a block_status request comes in in that range, it can be answered without doing a SEEK_HOLE/DATA), but that might suffer from the same problem of having to invalidate the cache too often. + +Though OTOH, as I also admitted on IRC, perhaps we should just try and see what happens. + + +As an afterthought, it might be cool to have file-posix use bitmaps to cache this status. In the simplest case, we could have one bitmaps that tells whether the block status is known (0 = known, 1 = unknown); this bitmap is active, so that writes would automatically invalidate the affected blocks. And then we have another bitmap that for the blocks of known status tells us whether they contain data or only zeroes. This solution wouldn’t suffer from a complete cache invalidation on every write. + +(Fine-tuning it, we could instead have both bitmaps be inactive, so that file-posix itself needs to update them on writes, so that all writes would give their respective blocks a known status, with data writes making them contain data, and zero writes making them contain zeroes.) + +(Perhaps we could consider offering this as a GSoC project?) + +By the way, as a side note: I see you’re using raw, but qcow2 tries to avoid deferring the block-status call to file-posix (i.e., it tries to avoid SEEK_HOLE/DATA calls), because in most cases it knows from its own metadata which block are zero. So I would guess that with qcow2, the problem would not occur. Do you have any data on that? + +We don't have currently issue with qcow2 for now, +In code it goes on different path: + +block/file-posix.c:3219:1: .bdrv_co_block_status = raw_co_block_status, +block/qcow2.c:5892:1: .bdrv_co_block_status = qcow2_co_block_status + +But when I run strace on qcow2 live migration I also see SEEK_HOLE/DATA +I will do more test in same condition than raw instances. + + +I’ve attached a patch to make file-posix cache the information about the last queried hole, does it help? + +It helps a lot, and it goes fast ! + +live block migration of 400GB raw disk: +master 1130s (362MB/s) qemu unstable/frozen +master+fix 445s (920MB/s) qemu stable + +Thanks Max, It will be nice to have this one merged. + +Some more data for Qcow2, + +Qcow2 format is not impacted by the issue because it +does not do SEEK_DATA/HOLE at all, because as you said it knows +from its own metadata. +But qcow2 instances with a RAW backing file does.. +So qcow2 instances laverage also benefit of the patch, +if they have big RAW backing file (or smaller but fragmented). +Openstack default is RAW backing file for qcow2 +instance images_type. + +I made others test on local mirror: +*57 GiB disk in on ssd, mirror file is on a nvme device +*the disk is on fragmented file + (Average size per extent 2125 KB, nb_extent: 28495, ext4) +*both qcow2 and raw test are run on the same fragmented file, + only content change(format/data). + +RESULTS +master____ RAW_________ 203s 291MB/s qemu freeze +master-fix RAW_________ 113s 523MB/s qemu stable (+56% perf) + +master____ QCOW2_______ 115s 505MB/s qemu stable +master-fix QCOW2_______ 116s 505MB/s qemu stable + +master____ QCOW2-SML_BF 113s 523MB/s qemu stable (1) +master-fix QCOW2-SML_BF 113s 523MB/s qemu stable (1) + +master____ QCOW2-BIG_BF 201s 294MB/s qemu freeze (2) +master-fix QCOW2-BIG_BF 112s 523MB/s qemu stable (2) (+56% perf) + + +(1) qcow2 disk with small RAW backing file (1.5GB) + big part of data are in qcow2 format + +(2) qcow2 disk with all data in RAW backing file (57GiB) + +Here are some stap metrics during test: +(see script at the end) + +find_allocation: total count of qemu find_allocation calls +iomap_seek_hole: count SEEK_HOLE (fs/iomap.c) +iomap_apply: count file extent iomap (fs/iomap.c) + +iomap_seek_hole loop iomap_apply calls on all file extent until +it finds a hole or EOF, it can be 1 up to 28495 in worst case +in the test file. + + +master____ RAW_________ 203s 291MB/s qemu freeze +find_allocation: 59139 +iomap_seek_hole: 59139 (each find_allocation call SEEK_HOLE) +iomap_apply: 843330989 (this breaks qemu) +master-fix RAW_________ 113s 523MB/s qemu stable (+56% perf) +find_allocation: 59167 +iomap_seek_hole: 4 (hole cache hit 99.993%) +iomap_apply: 113286 (avg iomap_apply call per SEEK_HOLE: 28321) + +master____ QCOW2_______ 115s 505MB/s qemu stable +find_allocation: 0 +iomap_seek_hole: 0 +iomap_apply: 0 +master-fix QCOW2_______ 116s 505MB/s qemu stable +find_allocation: 0 +iomap_seek_hole: 0 +iomap_apply: 0 + +master____ QCOW2-SML_BF 113s 523MB/s qemu stable (1) +find_allocation: 1418 +iomap_seek_hole: 1297 +iomap_apply: 7297 +master-fix QCOW2-SML_BF 113s 523MB/s qemu stable (1) +find_allocation: 1418 +iomap_seek_hole: 145 (hole cache hit 0.898%) +iomap_apply: 794 + +master____ QCOW2-BIG_BF 201s 294MB/s qemu freeze (2) +find_allocation: 59133 +iomap_seek_hole: 59133 +iomap_apply: 843172534 +master-fix QCOW2-BIG_BF 112s 523MB/s qemu stable (2) (+56% perf) +find_allocation: 59130 +iomap_seek_hole: 1 (hole cache hit 0.999%) +iomap_apply: 28494 + +################# seek_hole.stp ############################### +global iomap_apply, iomap_seek_hole, find_allocation +probe kernel.function("iomap_seek_hole").call { + if (pid() == target()) { + iomap_seek_hole ++ + } +} +probe kernel.function("iomap_apply").call { + if (pid() == target()) { + iomap_apply ++ + } +} +probe process("/usr/bin/qemu-system-x86_64").function("find_allocation").call { + if (pid() == target()) { + find_allocation ++ + } +} +probe end { + printf ("find_allocation: %d\niomap_seek_hole: %d\niomap_apply: %d\n",find_allocation, iomap_seek_hole, iomap_apply) +} + + + + + +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/307 + + diff --git a/results/classifier/105/KVM/1914353 b/results/classifier/105/KVM/1914353 new file mode 100644 index 00000000..c39aca8a --- /dev/null +++ b/results/classifier/105/KVM/1914353 @@ -0,0 +1,74 @@ +KVM: 0.974 +graphic: 0.775 +other: 0.747 +device: 0.739 +instruction: 0.720 +socket: 0.622 +mistranslation: 0.616 +vnc: 0.528 +semantic: 0.523 +network: 0.506 +boot: 0.416 +assembly: 0.347 + +QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID + +Via [qemu-security] list + ++-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+ +| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote: +| > Per the ARM Generic Interrupt Controller Architecture specification +| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit, +| > not 10: +| > +| > - Table 4-21 GICD_SGIR bit assignments +| > +| > The Interrupt ID of the SGI to forward to the specified CPU +| > interfaces. The value of this field is the Interrupt ID, in +| > the range 0-15, for example a value of 0b0011 specifies +| > Interrupt ID 3. +| > +... +| > Correct the irq mask to fix an undefined behavior (which eventually +| > lead to a heap-buffer-overflow, see [Buglink]): +| > +| > $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio +| > [I 1612088147.116987] OPENED +| > [R +0.278293] writel 0x8000f00 0xff4affb0 +| > ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]' +| > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13 +| > +| > Cc: <email address hidden> +| > Fixes: 9ee6e8bb853 ("ARMv7 support.") +| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916 +| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917 +... + +On 210202 1221, Peter Maydell wrote: +> In both cases the overrun is on the first writel to 0x8000f00, +> but the fuzzer has for some reason not reported that but instead +> blundered on until it happens to trigger some other issue that +> resulted from the memory corruption it induced with the first write. +> +... +> On the CVE: +> +> Since this can affect systems using KVM, this is a security bug for +> us. However, it only affects an uncommon configuration: +> you are only vulnerable if you are using "kernel-irqchip=off" +> (the default is 'on', and turning it off is an odd thing to do). +> +> thanks +> -- PMM +> + +Upstream patch: + -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00709.html + +CVE requested. + +'CVE-2021-20221' assigned by Red Hat Inc. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/edfe2eb4360cde4ed5d95bd + diff --git a/results/classifier/105/KVM/1914696 b/results/classifier/105/KVM/1914696 new file mode 100644 index 00000000..ffa2540d --- /dev/null +++ b/results/classifier/105/KVM/1914696 @@ -0,0 +1,137 @@ +KVM: 0.657 +vnc: 0.617 +other: 0.594 +mistranslation: 0.546 +graphic: 0.511 +device: 0.478 +instruction: 0.465 +semantic: 0.454 +assembly: 0.441 +boot: 0.437 +socket: 0.432 +network: 0.416 + +aarch64: migration failed: Segmentation fault (core dumped) + +reproduce: + +arch: aarch64 +source qemu: v4.2.0 +destination qemu: 1ed9228f63ea4bcc0ae240365305ee264e9189ce + +cmdline: +source: +$ ./aarch64-softmmu/qemu-system-aarch64 -name 'avocado-vt-vm1' -machine virt-4.2,gic-version=host,graphics=on -nodefaults -m 1024 -smp 2 -cpu 'host' -vnc :10 -enable-kvm -monitor stdio +(qemu) +(qemu) migrate -d tcp:10.19.241.167:888 +(qemu) info status +VM status: paused (postmigrate) + +destination: +./build/aarch64-softmmu/qemu-system-aarch64 -name 'avocado-vt-vm1' -machine virt-4.2,gic-version=host,graphics=on -nodefaults -m 1024 -smp 2 -cpu 'host' -vnc :10 -enable-kvm -monitor stdio -incoming tcp:0:888 +QEMU 5.2.50 monitor - type 'help' for more information +(qemu) Segmentation fault (core dumped) + + +i have bisected and confirmed that the first bad commit is: [f9506e162c33e87b609549157dd8431fcc732085] target/arm: Remove ARM_FEATURE_VFP* + +bisect log: +git bisect log +# bad: [1ed9228f63ea4bcc0ae240365305ee264e9189ce] Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-02-02-v2' into staging +git bisect bad 1ed9228f63ea4bcc0ae240365305ee264e9189ce +# good: [b0ca999a43a22b38158a222233d3f5881648bb4f] Update version for v4.2.0 release +git bisect good b0ca999a43a22b38158a222233d3f5881648bb4f +# bad: [59093cc407cb044c72aa786006a07bd404eb36b9] hw/char: Convert the Ibex UART to use the registerfields API +git bisect bad 59093cc407cb044c72aa786006a07bd404eb36b9 +# bad: [4dabf39592e92d692c6f2a1633571114ae25d843] aspeed/smc: Fix DMA support for AST2600 +git bisect bad 4dabf39592e92d692c6f2a1633571114ae25d843 +# good: [93c86fff53a267f657e79ec07dcd04b63882e330] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200207' into staging +git bisect good 93c86fff53a267f657e79ec07dcd04b63882e330 +# bad: [2ac031d171ccd18c973014d9978b4a63f0ad5fb0] Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-5.0-sf3' into staging +git bisect bad 2ac031d171ccd18c973014d9978b4a63f0ad5fb0 +# good: [4036b7d1cd9fb1097a5f4bc24d7d31744256260f] target/arm: Use isar_feature function for testing AA32HPD feature +git bisect good 4036b7d1cd9fb1097a5f4bc24d7d31744256260f +# good: [002375895c10df40615fc615e2639f49e0c442fe] tests/iotests: be a little more forgiving on the size test +git bisect good 002375895c10df40615fc615e2639f49e0c442fe +# good: [c695724868ce4049fd79c5a509880dbdf171e744] target/riscv: Emulate TIME CSRs for privileged mode +git bisect good c695724868ce4049fd79c5a509880dbdf171e744 +# good: [f67957e17cbf8fc3cc5d1146a2db2023404578b0] target/arm: Add isar_feature_aa32_{fpsp_v2, fpsp_v3, fpdp_v3} +git bisect good f67957e17cbf8fc3cc5d1146a2db2023404578b0 +# bad: [a1229109dec4375259d3fff99f362405aab7917a] target/arm: Implement v8.4-RCPC +git bisect bad a1229109dec4375259d3fff99f362405aab7917a +# bad: [906b60facc3d3dd3af56cb1a7860175d805e10a3] target/arm: Add formats for some vfp 2 and 3-register insns +git bisect bad 906b60facc3d3dd3af56cb1a7860175d805e10a3 +# good: [c52881bbc22b50db99a6c37171ad3eea7d959ae6] target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac +git bisect good c52881bbc22b50db99a6c37171ad3eea7d959ae6 +# good: [f0f6d5c81be47d593e5ece7f06df6fba4c15738b] target/arm: Move the vfp decodetree calls next to the base isa +git bisect good f0f6d5c81be47d593e5ece7f06df6fba4c15738b +# bad: [f9506e162c33e87b609549157dd8431fcc732085] target/arm: Remove ARM_FEATURE_VFP* +git bisect bad f9506e162c33e87b609549157dd8431fcc732085 +# good: [bfa8a370d2f5d4ed03f7a7e2987982f15fe73758] linux-user/arm: Replace ARM_FEATURE_VFP* tests for HWCAP +git bisect good bfa8a370d2f5d4ed03f7a7e2987982f15fe73758 +# first bad commit: [f9506e162c33e87b609549157dd8431fcc732085] target/arm: Remove ARM_FEATURE_VFP* + + +the root cause is that, some feature bit is not consistent any more with below changes in this commit: +diff --git a/target/arm/cpu.h b/target/arm/cpu.h +index b29b0eddfc..05aa9711cd 100644 +--- a/target/arm/cpu.h ++++ b/target/arm/cpu.h +@@ -1880,7 +1880,6 @@ QEMU_BUILD_BUG_ON(ARRAY_SIZE(((ARMCPU *)0)->ccsidr) <= R_V7M_CSSELR_INDEX_MASK); + * mapping in linux-user/elfload.c:get_elf_hwcap(). + */ + enum arm_features { +- ARM_FEATURE_VFP, + ARM_FEATURE_AUXCR, /* ARM1026 Auxiliary control register. */ + ARM_FEATURE_XSCALE, /* Intel XScale extensions. */ + ARM_FEATURE_IWMMXT, /* Intel iwMMXt extension. */ +@@ -1889,7 +1888,6 @@ enum arm_features { + ARM_FEATURE_V7, + ARM_FEATURE_THUMB2, + ARM_FEATURE_PMSA, /* no MMU; may have Memory Protection Unit */ +- ARM_FEATURE_VFP3, + ARM_FEATURE_NEON, + ARM_FEATURE_M, /* Microcontroller profile. */ + ARM_FEATURE_OMAPCP, /* OMAP specific CP15 ops handling. */ +@@ -1900,7 +1898,6 @@ enum arm_features { + ARM_FEATURE_V5, + ARM_FEATURE_STRONGARM, + ARM_FEATURE_VAPA, /* cp15 VA to PA lookups */ +- ARM_FEATURE_VFP4, /* VFPv4 (implies that NEON is v2) */ + ARM_FEATURE_GENERIC_TIMER, + ARM_FEATURE_MVFR, /* Media and VFP Feature Registers 0 and 1 */ + ARM_FEATURE_DUMMY_C15_REGS, /* RAZ/WI all of cp15 crn=15 */ + +paste the call trace + +(gdb) bt +#0 0x0000aaaac036a02c in armv7m_nvic_neg_prio_requested (opaque=0x0, secure=false) at ../hw/intc/armv7m_nvic.c:406 +#1 0x0000aaaac014dcf4 in arm_v7m_mmu_idx_for_secstate_and_priv (env=0xaaaaca23d950, secstate=false, priv=true) at ../target/arm/m_helper.c:2837 +#2 0x0000aaaac014dd8c in arm_v7m_mmu_idx_for_secstate (env=0xaaaaca23d950, secstate=false) at ../target/arm/m_helper.c:2848 +#3 0x0000aaaac018aa6c in arm_mmu_idx_el (env=0xaaaaca23d950, el=1) at ../target/arm/helper.c:12841 +#4 0x0000aaaac018b788 in rebuild_hflags_internal (env=0xaaaaca23d950) at ../target/arm/helper.c:13100 +#5 0x0000aaaac018b80c in arm_rebuild_hflags (env=0xaaaaca23d950) at ../target/arm/helper.c:13113 +#6 0x0000aaaac007f928 in cpu_post_load (opaque=0xaaaaca233b10, version_id=22) at ../target/arm/machine.c:767 +#7 0x0000aaaabfc8f508 in vmstate_load_state (f=0xaaaaca355520, vmsd=0xaaaac0d59ea8 <vmstate_arm_cpu>, opaque=0xaaaaca233b10, version_id=22) at ../migration/vmstate.c:168 +#8 0x0000aaaabfca3404 in vmstate_load (f=0xaaaaca355520, se=0xaaaaca2708b0) at ../migration/savevm.c:885 +#9 0x0000aaaabfca6410 in qemu_loadvm_section_start_full (f=0xaaaaca355520, mis=0xaaaaca204d90) at ../migration/savevm.c:2396 +#10 0x0000aaaabfca6a8c in qemu_loadvm_state_main (f=0xaaaaca355520, mis=0xaaaaca204d90) at ../migration/savevm.c:2582 +#11 0x0000aaaabfca6c34 in qemu_loadvm_state (f=0xaaaaca355520) at ../migration/savevm.c:2661 +#12 0x0000aaaabfd95bf0 in process_incoming_migration_co (opaque=0x0) at ../migration/migration.c:522 +#13 0x0000aaaac06c6248 in coroutine_trampoline (i0=-895198224, i1=43690) at ../util/coroutine-ucontext.c:173 +#14 0x0000ffffa5071f90 in __startcontext () at ../sysdeps/unix/sysv/linux/aarch64/setcontext.S:123 + + + +i have no a good idea how to fix it prefectly yet. + +This just came up on the list the other day. It should be fixed by this patch: +https://<email address hidden>/ + + +https://<email address hidden>/ works for me. + + +Fix now in master: commit af903caed9fc62cc6 + + diff --git a/results/classifier/105/KVM/1914748 b/results/classifier/105/KVM/1914748 new file mode 100644 index 00000000..935978ca --- /dev/null +++ b/results/classifier/105/KVM/1914748 @@ -0,0 +1,37 @@ +KVM: 0.970 +instruction: 0.906 +graphic: 0.801 +device: 0.781 +vnc: 0.699 +mistranslation: 0.646 +semantic: 0.623 +network: 0.530 +other: 0.416 +boot: 0.400 +socket: 0.345 +assembly: 0.137 + +Confuse error message when KVM can not start requested CPU + +As of commit 1ba089f2255, on Cavium CN8890 (ThunderX cores): + +$ qemu-system-aarch64 -display none -accel kvm -M virt,gic-version=3 -accel kvm -cpu cortex-a57 --trace \*kvm_vcpu\* +kvm_vcpu_ioctl cpu_index 0, type 0x4020aeae, arg 0xffff9b7f9b18 +qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument + +(same using "-cpu cortex-a53" or cortex-a72). + +Explanation from Peter Maydell on IRC: +> using a specific cpu type will only work with KVM if the host CPU really is that +> exact CPU type, otherwise, use "-cpu host" or "-cpu max" + +Having a better error description would help to understand the reason. + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/239 + + diff --git a/results/classifier/105/KVM/1915539 b/results/classifier/105/KVM/1915539 new file mode 100644 index 00000000..24713fc5 --- /dev/null +++ b/results/classifier/105/KVM/1915539 @@ -0,0 +1,120 @@ +KVM: 0.879 +vnc: 0.842 +mistranslation: 0.818 +other: 0.704 +semantic: 0.569 +graphic: 0.550 +device: 0.545 +instruction: 0.521 +boot: 0.421 +network: 0.416 +assembly: 0.415 +socket: 0.415 + +Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer + +== Reproducer == + +cat << EOF | ./qemu-system-i386 -display none \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-hd,drive=disk0 -machine accel=qtest -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0x10a 0x1 0x02 +write 0xe0000398 0x1 0x01 +write 0x20000 0x1 0x27 +write 0x20001 0x1 0x80 +write 0x20002 0x1 0x20 +write 0x20005 0x1 0x02 +write 0xe00003b8 0x2 0x0101 +write 0xe0000004 0x1 0x01 +write 0x2bb 0x1 0x00 +write 0x2bf 0x1 0x00 +write 0x2cf 0x1 0x00 +write 0x2db 0x1 0x00 +write 0x2df 0x1 0x00 +write 0x2ed 0x1 0x00 +write 0x2ef 0x1 0x00 +write 0x2fb 0x1 0x00 +write 0x2ff 0x1 0x00 +write 0x31f 0x1 0x00 +write 0x32b 0x1 0x00 +write 0x32f 0x1 0x00 +write 0x337 0x1 0x00 +write 0x33f 0x1 0x00 +write 0x347 0x1 0x00 +write 0x357 0x1 0x00 +write 0x35f 0x1 0x00 +write 0x36b 0x1 0x00 +write 0x36f 0x1 0x00 +write 0x377 0x1 0x00 +write 0x37f 0x1 0x00 +write 0x397 0x1 0x00 +write 0x39f 0x1 0x00 +write 0x3ab 0x1 0x00 +write 0x3af 0x1 0x00 +write 0x3b7 0x1 0x00 +write 0x3bf 0x1 0x00 +write 0x3c7 0x1 0x00 +write 0x3d7 0x1 0x00 +write 0x3df 0x1 0x00 +write 0x3eb 0x1 0x00 +write 0x3ef 0x1 0x00 +write 0x3f7 0x1 0x00 +write 0x3ff 0x1 0x00 +write 0xe0000394 0x1 0x00 +write 0xe0000398 0x1 0x01 +EOF + +== Stack Trace == +../hw/ide/ahci.c:1349:46: runtime error: member access within null pointer of +type 'AHCICmdHdr' (aka 'struct AHCICmdHdr') SUMMARY: +UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1349:46 in +../hw/ide/ahci.c:1349:46: runtime error: load of null pointer of type +'uint16_t' (aka 'unsigned short') +SUMMARY: UndefinedBehaviorSanitizer: +undefined-behavior ../hw/ide/ahci.c:1349:46 in AddressSanitizer:DEADLYSIGNAL +================================================================= +==238806==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc +0x555787d414c9 bp 0x7fffe1bb41a0 sp 0x7fffe1bb3fe0 T0) +==238806==The signal is caused by a READ memory access. +==238806==Hint: address points to the zero page. +#0 0x555787d414c9 in ahci_pio_transfer build/../hw/ide/ahci.c:1349:46 +#1 0x5557886089d6 in ide_transfer_start_norecurse build/../hw/ide/core.c:553:5 +#2 0x555788638945 in ide_transfer_start build/../hw/ide/core.c:560:9 +#3 0x555788638945 in ide_sector_read_cb build/../hw/ide/core.c:761:5 +#4 0x55578860c989 in ide_buffered_readv_cb build/../hw/ide/core.c:656:9 +#5 0x5557898999d6 in blk_aio_complete build/../block/block-backend.c:1412:9 +#6 0x555789db8d26 in aio_bh_poll build/../util/async.c:164:13 +#7 0x555789d80704 in aio_dispatch build/../util/aio-posix.c:381:5 +#8 0x555789dbd94c in aio_ctx_dispatch build/../util/async.c:306:5 +#9 0x7f6dcedcfbaa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa) +#10 0x555789dc3763 in glib_pollfds_poll build/../util/main-loop.c:232:9 +#11 0x555789dc3763 in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#12 0x555789dc3763 in main_loop_wait build/../util/main-loop.c:531:11 +#13 0x555789206a49 in qemu_main_loop build/../softmmu/runstate.c:722:9 +#14 0x555787d052ed in main build/../softmmu/main.c:50:5 +#15 0x7f6dcd84ecc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#16 0x555787c5b619 in _start (system-i386+0x2a13619) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV build/../hw/ide/ahci.c:1349:46 in ahci_pio_transfer +==238806==ABORTING + +OSS-Fuzz link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30861 + +Confirmed. Please migrate to gitlab and assign me. + +--js + + +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/341 + + diff --git a/results/classifier/105/KVM/1919036 b/results/classifier/105/KVM/1919036 new file mode 100644 index 00000000..82a1e3b8 --- /dev/null +++ b/results/classifier/105/KVM/1919036 @@ -0,0 +1,178 @@ +KVM: 0.736 +mistranslation: 0.729 +other: 0.704 +graphic: 0.689 +vnc: 0.633 +device: 0.608 +instruction: 0.591 +semantic: 0.584 +assembly: 0.523 +boot: 0.491 +socket: 0.489 +network: 0.477 + +Assertion failure in fifo8_push_all() through am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master, 3f8d1885e4) + + +``` +qemu-system-i386: ../util/fifo8.c:43: fifo8_push_all: Assertion `fifo->num + num <= fifo->capacity' failed. + +#0 0x00007ffff0218fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007ffff021a921 in __GI_abort () at abort.c:79 +#2 0x00007ffff020a48a in __assert_fail_base (fmt=0x7ffff0391750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555558ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x555558ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") + at assert.c:92 +#3 0x00007ffff020a502 in __GI___assert_fail (assertion=assertion@entry=0x555558ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x555558ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") at assert.c:101 +#4 0x00005555587749c4 in fifo8_push_all (fifo=fifo@entry=0x61f000005200, data=data@entry=0x7fff72bfa640 "", num=num@entry=0x24) at ../util/fifo8.c:43 +#5 0x00005555572bd13e in esp_do_dma (s=s@entry=0x61f000005088) at ../hw/scsi/esp.c:577 +#6 0x00005555572bfc8f in handle_ti (s=0x61f000005088) at ../hw/scsi/esp.c:845 +#7 0x00005555572c419c in esp_reg_write (s=0x61f000005088, saddr=saddr@entry=0x3, val=<optimized out>) + at ../hw/scsi/esp.c:987 +#8 0x0000555557bb916a in esp_pci_io_write (opaque=0x61f000004680, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at ../hw/scsi/esp-pci.c:214 +#9 0x000055555817ea28 in memory_region_write_accessor (mr=0x61f000004f70, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:491 +#10 0x0000555558176671 in access_with_adjusted_size (addr=addr@entry=0xc, value=value@entry=0x7fff72bfb2a8, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn= + 0x55555817e7c0 <memory_region_write_accessor>, mr=0x61f000004f70, attrs=...) at ../softmmu/memory.c:552 +#11 0x00005555581892aa in memory_region_dispatch_write (mr=mr@entry=0x61f000004f70, addr=<optimized out>, data=<optimized out>, data@entry=0xffffff90, op=op@entry=MO_8, attrs=..., attrs@entry=...) at ../softmmu/memory.c:1508 +#12 0x0000555558024b66 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=<optimized out>, attrs=..., result=0x0) at /home/cwmyung/prj/hyfuzz/src/qemu-master/memory_ldst.c.inc:382 +#13 0x00007fff9323641c in code_gen_buffer () +#14 0x0000555557e793bb in cpu_tb_exec (tb_exit=<optimized out>, itb=<optimized out>, cpu=0x62e0000004b4) + at ../accel/tcg/cpu-exec.c:190 +#15 0x0000555557e793bb in cpu_loop_exec_tb (tb_exit=<optimized out>, last_tb=<optimized out>, tb=<optimized out>, cpu=0x62e0000004b4) at ../accel/tcg/cpu-exec.c:673 +#16 0x0000555557e793bb in cpu_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/cpu-exec.c:798 +#17 0x0000555557f5fc5a in tcg_cpus_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops.c:68 +#18 0x00005555582260af in mttcg_cpu_thread_fn (arg=arg@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 +#19 0x0000555558777b05 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#20 0x00007ffff05d26db in start_thread (arg=0x7fff72bff700) at pthread_create.c:463 +#21 0x00007ffff02fb71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` + + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +``` + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + +Thanks for the test case - looks like the problem occurs because a command hasn't been submitted before initiating a DMA transfer, and TC is set to a value higher than the size of cmdfifo. Can you confirm that the following fix works for you? + +diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c +index 507ab363bc..0a26ee1dfd 100644 +--- a/hw/scsi/esp.c ++++ b/hw/scsi/esp.c +@@ -573,6 +573,7 @@ static void esp_do_dma(ESPState *s) + cmdlen = fifo8_num_used(&s->cmdfifo); + trace_esp_do_dma(cmdlen, len); + if (s->dma_memory_read) { ++ len = MIN(len, fifo8_num_free(&s->cmdfifo)); + s->dma_memory_read(s->dma_opaque, buf, len); + fifo8_push_all(&s->cmdfifo, buf, len); + } else { + + +ATB, + +Mark. + +QTest Reproducer: +/* + * Autogenerated Fuzzer Test Case + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ + * -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ + * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio + * outl 0xcf8 0x80001004 + * outw 0xcfc 0x01 + * outl 0xcf8 0x8000100e + * outl 0xcfc 0x0e000000 + * outl 0xe40 0x03 + * outl 0xe0b 0x4100 + * outl 0xe0b 0x9000 + * EOF + */ +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 512M -device am53c974,id=scsi -device " + "scsi-hd,drive=disk0 -drive " + "id=disk0,if=none,file=null-co://,format=raw -nodefaults"); + qtest_outl(s, 0xcf8, 0x80001004); + qtest_outw(s, 0xcfc, 0x01); + qtest_outl(s, 0xcf8, 0x8000100e); + qtest_outl(s, 0xcfc, 0x0e000000); + qtest_outl(s, 0xe40, 0x03); + qtest_outl(s, 0xe0b, 0x4100); + qtest_outl(s, 0xe0b, 0x9000); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + +Hello Mark, + +I tested on fixed version, and checked that it does not trigger the assertion failure. + +Thanks, +- Cheolwoo Myung + +Thank you both for the reproducers. Please see the proposed patchset here: + +https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06063.html + + +This is fixed now, thank you Mark. + +Patchset v4: +https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01000.html + +Upstream commits: +https://git.qemu.org/?p=qemu.git;a=commit;h=0db895361b8a82e1114372ff9f48 +https://git.qemu.org/?p=qemu.git;a=commit;h=e392255766071c8cac480da3a9ae +https://git.qemu.org/?p=qemu.git;a=commit;h=e5455b8c1c6170c788f3c0fd577c +https://git.qemu.org/?p=qemu.git;a=commit;h=c5fef9112b15c4b5494791cdf8bb +https://git.qemu.org/?p=qemu.git;a=commit;h=7b320a8e67a534925048cbabfa51 +https://git.qemu.org/?p=qemu.git;a=commit;h=99545751734035b76bd372c4e721 +https://git.qemu.org/?p=qemu.git;a=commit;h=fa7505c154d4d00ad89a747be2ed +https://git.qemu.org/?p=qemu.git;a=commit;h=fbc6510e3379fa8f8370bf71198f +https://git.qemu.org/?p=qemu.git;a=commit;h=0ebb5fd80589835153a0c2baa1b8 +https://git.qemu.org/?p=qemu.git;a=commit;h=324c8809897c8c53ad05c3a7147d +https://git.qemu.org/?p=qemu.git;a=commit;h=607206948cacda4a80be5b976dba + +I'm not able to change the status of this bug anymore. It should have been closed as "Fix committed" - QEMU 6.0.0 is not yet released. + diff --git a/results/classifier/105/KVM/1919169 b/results/classifier/105/KVM/1919169 new file mode 100644 index 00000000..b291f8b0 --- /dev/null +++ b/results/classifier/105/KVM/1919169 @@ -0,0 +1,34 @@ +KVM: 0.928 +graphic: 0.912 +device: 0.870 +boot: 0.867 +semantic: 0.827 +instruction: 0.820 +other: 0.805 +mistranslation: 0.770 +vnc: 0.750 +socket: 0.721 +network: 0.691 +assembly: 0.245 + +[git]Startup crash when trying to use an EFI enabled VM in accel/kvm/kvm-all.c + +Hello. + +I build a git version based on commit 6157b0e19721aadb4c7fdcfe57b2924af6144b14. + +When I try to launch an EFI enabled VM, it crashes on start. Here is the command line used: + +qemu-system-x86_64 -bios /usr/share/edk2-ovmf/x64/OVMF.fd -enable-kvm -smp 4 -soundhw all -k fr -m 4096 -vga qxl -hda disk.img -cdrom archlinux-2021.03.01-x86_64.iso -boot cd & + +Here is the log I get: + +``` +qemu-system-x86_64: ../accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: Assertion `QEMU_IS_ALIGNED(start | size, psize)' failed. +``` + + +ed2k-ovmf version: 202102 + +I tried an older version, edk2-ovmf 202011, same crash on start. + diff --git a/results/classifier/105/KVM/1921635 b/results/classifier/105/KVM/1921635 new file mode 100644 index 00000000..80ea8a52 --- /dev/null +++ b/results/classifier/105/KVM/1921635 @@ -0,0 +1,172 @@ +KVM: 0.536 +other: 0.486 +vnc: 0.433 +mistranslation: 0.363 +graphic: 0.337 +device: 0.335 +instruction: 0.331 +semantic: 0.323 +boot: 0.320 +assembly: 0.314 +network: 0.306 +socket: 0.299 + +ESP SCSI adapter not working with DOS ASPI drivers + +I have been trying to install the DOS ASPI drivers for the ESP scsi card. Both in am53c974 and dc390 modes. Neither works but they don't work in different ways. + +The following things appear to be problematic: + +* The am53c974 should work with the PcSCSI drivers (AMSIDA.SYS) but the ASPI driver never manages to get past initializing the card. The VM never continues. +* The dc390 ASPI driver fares a little better. The ASPI driver loads and is semi-functional but the drivers for the peripherals don't work. + - ASPI.SYS (creative name) loads + - TRMDISK.SYS fails to load when a cd-drive is attached and will crashs scanning the scsi-id where the cd drive is attached + - TRMDISK.SYS loads without a CD drive attached but fails to read any scsi-hd devices attached. The TFDISK.EXE formatter crashes. + - TRMCD.SYS loads, but can not detect any CD drives. + +The various permutations: +am53c974 hang on ASPI driver load: (CD only attached) + +~/src/qemu/build/qemu-system-i386 -m 64 -device am53c974,id=scsi0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda am53c974_aspi.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 crash because of CDROM attachment and loading TRMDISK.SYS (Only CD attached) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, but TRMDISK.SYS not working (TFDISK.EXE will crash) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0,logical_block_size=512 -drive file=small.qcow2,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, TRMDISK.SYS not loaded, only TRMCD.SYS. CDROM not detected +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_cd.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +All of these tests were done on 7b9a3c9f94bcac23c534bc9f42a9e914b433b299 as well as the 'esp-next' branch found here: https://github.com/mcayland/qemu/tree/esp-next + +The bios file is a seabios master with all int13 support disabled. With it enabled even less works but I figured this would be a seabios bug and not a qemu one. + +The actual iso and qcow2 files used don't appear the matter. the 'small.qcow2' is an empty drive of 100MB. I have also tried other ISOs in the CD drives, or even not put any cd in the drives with the same results. + +I will attach all of the above images. + + + + + + + + + + + +Something maybe worth noting is that the DC390 driver detectes attached CDROM drives as 'Fixed Disks' which seems a little fishy. The same appears to happen with the lsilogic card (that is cdrom drives get detected as hard drives and causes a failure to load the drivers) + +I've had a look at your am53c974 boot floppy with PcSCSI drivers and I'm fairly sure that disabling INT13 support isn't helping here. With your custom SeaBIOS I see a hang issuing the first SCSI command: without your custom SeaBIOS I can see that the default SeaBIOS issues several successful commands to the SCSI bus before booting from the floppy. + +Dropping the -bios option and booting your floppy here I see the following sequence with -trace 'scsi*' -trace 'esp*' after the BIOS has initialised: + + +esp_mem_writeb reg[3]: 0x42 -> 0x02 +esp_mem_writeb_cmd_reset Chip reset (0x02) +esp_mem_writeb reg[3]: 0x02 -> 0x80 +esp_mem_writeb_cmd_nop NOP (0x80) +esp_mem_writeb reg[11]: 0x00 -> 0x40 +esp_mem_readb reg[14]: 0x12 +esp_pci_sbac_read sbac: 0x00000000 +esp_pci_sbac_write sbac: 0x00000000 -> 0x02000000 +esp_mem_writeb reg[3]: 0x80 -> 0x02 +esp_mem_writeb_cmd_reset Chip reset (0x02) +esp_mem_writeb reg[3]: 0x02 -> 0x80 +esp_mem_writeb_cmd_nop NOP (0x80) +esp_mem_writeb reg[8]: 0x00 -> 0x17 +esp_mem_writeb reg[12]: 0x00 -> 0x88 +esp_mem_writeb reg[13]: 0x00 -> 0x40 +esp_mem_writeb reg[11]: 0x00 -> 0x40 +esp_mem_writeb reg[9]: 0x00 -> 0x07 +esp_mem_writeb reg[5]: 0x00 -> 0x8d +esp_mem_writeb reg[5]: 0x8d -> 0x02 +esp_mem_readb reg[8]: 0x17 +esp_mem_writeb reg[8]: 0x17 -> 0x07 +esp_mem_writeb reg[4]: 0x00 -> 0x00 +esp_mem_writeb reg[3]: 0x80 -> 0x01 +esp_mem_writeb_cmd_flush Flush FIFO (0x01) +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[2]: 0x00 -> 0x00 +esp_mem_writeb reg[3]: 0x01 -> 0x41 +esp_mem_writeb_cmd_sel Select without ATN (0x41) +esp_get_cmd len 6 target 0 +esp_do_busid_cmd busid 0x0 +scsi_req_parsed target 0 lun 0 tag 0 command 0 dir 0 length 0 +scsi_req_parsed_lba target 0 lun 0 tag 0 command 0 lba 0 +scsi_req_alloc target 0 lun 0 tag 0 +scsi_disk_new_request Command: lun=0 tag=0x0 data= 0x00 0x00 0x00 0x00 0x00 0x00 +scsi_test_unit_ready target 0 lun 0 tag 0 +scsi_req_dequeue target 0 lun 0 tag 0 +esp_command_complete SCSI Command complete +esp_raise_irq Raise IRQ +esp_lower_drq Lower DREQ + +****** +esp_pci_dma_read reg[5]: 0x00000018 +esp_mem_readb reg[4]: 0x93 +esp_mem_readb reg[6]: 0x00 +esp_lower_irq Lower IRQ +esp_mem_readb reg[5]: 0x18 +esp_mem_readb reg[8]: 0x07 +esp_mem_writeb reg[8]: 0x07 -> 0x47 +esp_mem_writeb reg[3]: 0x41 -> 0x03 +esp_mem_writeb_cmd_bus_reset Bus reset (0x03) +****** + + +The loading of the "test unit ready" command and execution look fine to me: QEMU's SCSI layer is executing the command (indicating success) and raises the ESP IRQ. However at this point in the section marked by "******" the ASPI driver seems not be happy with the RSTAT/RINTR register contents or the 0x18 read back from the PCI DMA registers, issues a bus reset and stops. + +What is interesting here is that the "Select without ATN (0x41)" command issued is a non-DMA command so I wouldn't expect it to affect the ESP PCI DMA register state, but I suspect you'll need to have a look what the driver is doing using a disassembler/gdbstub and the am53c974 datasheet to try and understand what is happening here. + +Finally it may be worth checking the IRQ routing with -trace 'pci*' to see if SeaBIOS updates the PCI "Interrupt Pin" register indicating where it thinks the IRQ should be routed, and stepping through the esp_raise_irq() in QEMU for the final test unit ready command to ensure that all of QEMU, SeaBIOS and AMSIDA.SYS all agree on what IRQ is being used. + +I'm looking at this document: http://bitsavers.trailing-edge.com/components/amd/_dataSheets/1993_53c974_PCscsi.pdf + +But I can't find this RSTAT/RINTR register in it. Am I looking at the wrong document, or is there a name mapping to the official names that I'm missing? + +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.] + + +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/569 + + diff --git a/results/classifier/105/KVM/1922430 b/results/classifier/105/KVM/1922430 new file mode 100644 index 00000000..4cc96154 --- /dev/null +++ b/results/classifier/105/KVM/1922430 @@ -0,0 +1,84 @@ +KVM: 0.954 +graphic: 0.913 +device: 0.882 +instruction: 0.881 +boot: 0.863 +other: 0.857 +assembly: 0.856 +semantic: 0.843 +socket: 0.837 +network: 0.804 +mistranslation: 0.770 +vnc: 0.665 + +3d accel does not take care of 1280x960 setting + +openSuse 15.2 +kde plasma 5.21.3, frameworks 5.80.0 +libvirt 7.0.0 +qemu 5.2.0 +virgl renderer 0.8.2 + +here is my invocation + +qemu-kvm -enable-kvm \ +-m 2048 -smp 2 -cpu host \ +-device virtio-vga,virgl=on -display gtk,gl=on \ +-device usb-ehci \ +-device usb-kbd \ +-device usb-mouse \ +-device usb-tablet \ +-device ich9-intel-hda \ +-device hda-duplex,audiodev=snd0 \ +-audiodev pa,id=snd0 \ +-device usb-host,vendorid=0x046d,productid=0x08e5 \ +-boot menu=on \ +-nic bridge \ +~/QEMU_VM/android_x86_7.1-r5.img \ + +in the kernel command there is "vga=1280x960" + +with "-device qxl" no problem. I get immediately a window of size 1280x960. + +with "-device virtio-vga,virgl=on -display gtk,gl=on" + +i get a tiny window. + +i must uncheck "zoom to fit" to get a window of size 1280x960. + +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. + + +done + +Ticket has been moved here (thanks!): +https://gitlab.com/qemu-project/qemu/-/issues/315 +... so I'm closing this on Launchpad now. + diff --git a/results/classifier/105/KVM/1924231 b/results/classifier/105/KVM/1924231 new file mode 100644 index 00000000..6a423fec --- /dev/null +++ b/results/classifier/105/KVM/1924231 @@ -0,0 +1,129 @@ +KVM: 0.714 +graphic: 0.597 +other: 0.571 +vnc: 0.562 +instruction: 0.552 +mistranslation: 0.499 +semantic: 0.489 +device: 0.477 +assembly: 0.393 +network: 0.331 +boot: 0.322 +socket: 0.245 + +Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on. + +the QEMU release version where the bug was found. + +apt list --installed | grep qemu +qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.14 amd64 [installed] + + +The installing "libc-bin" which "wget" depends on crashes as below when we execute docker image of Debian GNU/Linux bullseye for ARM64 on Ubuntu 20.04 for AMD64. +This problem also occurs on CI(GitHub Actions)(https://github.com/groonga/groonga/runs/2338497272?check_suite_focus=true#step:11:127). +Probably, The cause of this crash is https://bugs.launchpad.net/qemu/+bug/1749393. +This bug has already been fixed in qemu-user-static pacakge for Ubuntu 20.10. + +However, this fix is not included in qemu-user-static pacakge for Ubuntu 20.04. +Currently, GitHub Actions does not support Ubuntu 20.10. +Therefore, this problem is still happening in CI. + +Would it be possible for you to backport this fix into Ubuntu 20.04? + + +How to reproduce: + +sudo apt install -y qemu-user-static docker.io +sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt install -y wget' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB] +Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] +Get:3 http://deb.debian.org/debian bullseye-updates InRelease [40.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 Packages [8084 kB] +Get:5 http://security.debian.org/debian-security bullseye-security/main arm64 Packages [808 B] +Fetched 8311 kB in 4s (2001 kB/s) +Reading package lists... +Building dependency tree... +Reading state information... +2 packages can be upgraded. Run 'apt list --upgradable' to see them. + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Reading package lists... +Building dependency tree... +Reading state information... +The following additional packages will be installed: + ca-certificates libpsl5 openssl publicsuffix +The following NEW packages will be installed: + ca-certificates libpsl5 openssl publicsuffix wget +0 upgraded, 5 newly installed, 0 to remove and 2 not upgraded. +Need to get 2111 kB of archives. +After this operation, 5844 kB of additional disk space will be used. +Get:1 http://deb.debian.org/debian bullseye/main arm64 openssl arm64 1.1.1k-1 [829 kB] +Get:2 http://deb.debian.org/debian bullseye/main arm64 ca-certificates all 20210119 [158 kB] +Get:3 http://deb.debian.org/debian bullseye/main arm64 libpsl5 arm64 0.21.0-1.2 [57.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 wget arm64 1.21-1 [946 kB] +Get:5 http://deb.debian.org/debian bullseye/main arm64 publicsuffix all 20210108.1309-1 [121 kB] +debconf: delaying package configuration, since apt-utils is not installed +Fetched 2111 kB in 0s (12.9 MB/s) +Selecting previously unselected package openssl. +(Reading database ... 6640 files and directories currently installed.) +Preparing to unpack .../openssl_1.1.1k-1_arm64.deb ... +Unpacking openssl (1.1.1k-1) ... +Selecting previously unselected package ca-certificates. +Preparing to unpack .../ca-certificates_20210119_all.deb ... +Unpacking ca-certificates (20210119) ... +Selecting previously unselected package libpsl5:arm64. +Preparing to unpack .../libpsl5_0.21.0-1.2_arm64.deb ... +Unpacking libpsl5:arm64 (0.21.0-1.2) ... +Selecting previously unselected package wget. +Preparing to unpack .../archives/wget_1.21-1_arm64.deb ... +Unpacking wget (1.21-1) ... +Selecting previously unselected package publicsuffix. +Preparing to unpack .../publicsuffix_20210108.1309-1_all.deb ... +Unpacking publicsuffix (20210108.1309-1) ... +Setting up libpsl5:arm64 (0.21.0-1.2) ... +Setting up wget (1.21-1) ... +Setting up openssl (1.1.1k-1) ... +Setting up publicsuffix (20210108.1309-1) ... +Setting up ca-certificates (20210119) ... +debconf: unable to initialize frontend: Dialog +debconf: (TERM is not set, so the dialog frontend is not usable.) +debconf: falling back to frontend: Readline +debconf: unable to initialize frontend: Readline +debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) +debconf: falling back to frontend: Teletype +Updating certificates in /etc/ssl/certs... +129 added, 0 removed; done. +Processing triggers for libc-bin (2.31-11) ... +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +dpkg: error processing package libc-bin (--configure): + installed libc-bin package post-installation script subprocess returned error exit status 139 +Processing triggers for ca-certificates (20210119) ... +Updating certificates in /etc/ssl/certs... +0 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d... +done. +Errors were encountered while processing: + libc-bin +E: Sub-process /usr/bin/dpkg returned an error code (1) + +This is the bug tracker for upstream QEMU. If you'd like to request Ubuntu to backport some fix into their packages of QEMU, you'll need to file it against the Ubuntu QEMU package bug tracker. Since those bugs are also tracked in Launchpad, I'll try re-componenting this bug report to the Ubuntu QEMU package... + + +I'm sorry that I send a wrong destination of report. +Thank you for re-componenting this bug report. + +Thank you for taking the time to report this bug and helping to make Ubuntu better. + +In Launchpad we use one bug per issue. Since this issue is already reported in bug 1749393, I'm marking this bug as a duplicate of that one. + +You're requesting to backport the fix to 20.04. We can track this in the other bug with a bug task, which I'll open now. + +Status changed to 'Confirmed' because the bug affects multiple users. + diff --git a/results/classifier/105/KVM/1924914 b/results/classifier/105/KVM/1924914 new file mode 100644 index 00000000..1f7e62c8 --- /dev/null +++ b/results/classifier/105/KVM/1924914 @@ -0,0 +1,103 @@ +KVM: 0.803 +mistranslation: 0.760 +other: 0.752 +graphic: 0.706 +device: 0.684 +vnc: 0.676 +semantic: 0.667 +instruction: 0.657 +boot: 0.642 +network: 0.624 +assembly: 0.621 +socket: 0.541 + +Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver) + +System is Arch Linux (guest and host OS). + +Problem: + +Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. + +This is the command I use to run my guest: + +qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 + +This doesn't happen when I use X with i3-wm. + + + +I can't get it to happen with -vga qxl. + +I can't reproduce it with weston. + +-cpu host -smp 4 makes the hang/freeze go away. + +From the dmesg above: + +[ 573.935889] Oops: 0000 [#1] PREEMPT SMP PTI +[ 573.935892] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.11.11-arch1-1 #1 +[ 573.935896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.14.0-1 04/01/2014 +[ 573.935899] Workqueue: events_unbound commit_work [drm_kms_helper] +[ 573.935949] RIP: 0010:dma_fence_wait_timeout+0x20/0x110 +[ 573.935953] Code: 5c 41 5d 41 5e 41 5f c3 66 90 0f 1f 44 00 00 41 54 55 53 48 83 ec 08 48 85 d2 0f 88 da 00 00 00 48 89 fd 89 f3 0f 1f 44 00 00 <48> 8b 45 08 0f b6 f3 48 89 ef 48 8b 40 28 48 85 c0 0f 84 ac 00 00 +[ 573.935956] RSP: 0018:ffffbbf100043db0 EFLAGS: 00010206 +[ 573.935958] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001 +[ 573.935959] RDX: 7fffffffffffffff RSI: 0000000000000001 RDI: 0000000000000000 +[ 573.935961] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff90631e171bc0 +[ 573.935962] R10: 0000000000000001 R11: 0000000000000001 R12: ffff906408336000 +[ 573.935964] R13: ffff906380260cc0 R14: ffff906401700000 R15: 0000000000000005 +[ 573.935966] FS: 0000000000000000(0000) GS:ffff90643bc00000(0000) knlGS:0000000000000000 +[ 573.935967] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 573.935969] CR2: 0000000000000008 CR3: 000000011ed86000 CR4: 00000000000006f0 +[ 573.935973] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 573.935974] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 573.935976] Call Trace: +[ 573.935983] ? virtio_gpu_notify+0x46/0x60 [virtio_gpu] +[ 573.935995] virtio_gpu_cursor_plane_update+0x1c3/0x2a0 [virtio_gpu] +[ 573.936005] drm_atomic_helper_commit_planes+0xb7/0x220 [drm_kms_helper] +[ 573.936024] drm_atomic_helper_commit_tail+0x42/0x80 [drm_kms_helper] +[ 573.936038] commit_tail+0xce/0x130 [drm_kms_helper] +[ 573.936050] process_one_work+0x214/0x3e0 +[ 573.936054] worker_thread+0x4d/0x3d0 +[ 573.936056] ? rescuer_thread+0x3c0/0x3c0 +[ 573.936058] kthread+0x133/0x150 +[ 573.936061] ? __kthread_bind_mask+0x60/0x60 +[ 573.936064] ret_from_fork+0x22/0x30 +[ 573.936072] Modules linked in: cfg80211 rfkill ghash_generic gf128mul cryptd gcm ccm algif_aead des_generic libdes cbc ecb algif_skcipher cmac md4 algif_hash af_alg ppdev pktcdvd parport_pc parport i2c_piix4 joydev mousedev mac_hid psmouse qemu_fw_cfg pcspkr pkcs8_key_parser speakup_soft speakup fuse bpf_preload ip_tables x_tables overlay squashfs loop isofs sr_mod cdrom ata_generic pata_acpi virtio_gpu virtio_dma_buf drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm intel_agp intel_gtt serio_raw e1000 virtio_pci ata_piix agpgart floppy +[ 573.936161] CR2: 0000000000000008 +[ 573.936163] ---[ end trace 0f1e24b3ea0a35cd ]--- +[ 573.936165] RIP: 0010:dma_fence_wait_timeout+0x20/0x110 + +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/105/KVM/1926596 b/results/classifier/105/KVM/1926596 new file mode 100644 index 00000000..2dbe930b --- /dev/null +++ b/results/classifier/105/KVM/1926596 @@ -0,0 +1,80 @@ +KVM: 0.961 +graphic: 0.921 +other: 0.885 +instruction: 0.845 +device: 0.840 +semantic: 0.807 +mistranslation: 0.759 +network: 0.700 +vnc: 0.631 +socket: 0.615 +assembly: 0.493 +boot: 0.457 + +qemu-monitor-event command gets stuck randomly + +We are using kvm virtualization on our servers, We use "qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them we use "qemu-monitor-event" command +For eg:- +/usr/bin/virsh qemu-monitor-event VPSNAME --event "BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex + +the above command stucks randomly (backup completes but still it is waiting) and because of which other vms backup are stucked until we kill that process. + +Can you suggest how can we debug this further to find the actual issue. + + +/usr/bin/virsh version + +Compiled against library: libvirt 4.5.0 +Using library: libvirt 4.5.0 +Using API: QEMU 4.5.0 +Running hypervisor: QEMU 2.0.0 + +cat /etc/os-release +NAME="CentOS Linux" +VERSION="7 (Core)" +ID="centos" +ID_LIKE="rhel fedora" +VERSION_ID="7" +PRETTY_NAME="CentOS Linux 7 (Core)" +ANSI_COLOR="0;31" +CPE_NAME="cpe:/o:centos:centos:7" +HOME_URL="https://www.centos.org/" +BUG_REPORT_URL="https://bugs.centos.org/" + +CENTOS_MANTISBT_PROJECT="CentOS-7" +CENTOS_MANTISBT_PROJECT_VERSION="7" +REDHAT_SUPPORT_PRODUCT="centos" +REDHAT_SUPPORT_PRODUCT_VERSION="7" + +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/105/KVM/1926782 b/results/classifier/105/KVM/1926782 new file mode 100644 index 00000000..da1276cf --- /dev/null +++ b/results/classifier/105/KVM/1926782 @@ -0,0 +1,76 @@ +KVM: 0.886 +other: 0.883 +vnc: 0.860 +network: 0.859 +instruction: 0.857 +assembly: 0.853 +semantic: 0.850 +graphic: 0.847 +mistranslation: 0.846 +device: 0.844 +socket: 0.844 +boot: 0.830 + +configure script --extra-cflags not passed to config-meson.cross + +Since qemu 5.2, when building, the configure would not finish, but would return this error instead: + + qemu ../meson.build:852:2: ERROR: C header 'sasl/sasl.h' not found + +This is for a cross build, and I invoke qemu with the --extra-cflags and --extra-ldflags containing all the proper paths to the headers, libraries etc. It worked properly with qemu 3.1 to 5.1. + +After looking into the configure script, it seems that meson is passed the CFLAGS environment variable instead of QEMU_CFLAGS, and only the latter contains the --extra-cflags argument: + + echo "c_args = [${CFLAGS:+$(meson_quote $CFLAGS)}]" >> $cross + +Using the CFLAGS and LDFLAGS environment variable instead of --extra-cflags and --extra-ldflags fixes the issue. + +Here is my full invocation of the configure script: + +CFLAGS=" -isystem /home/anisse/dev/qemu-cross/build/usr/include" \ +LDFLAGS="-Wl,--gc-sections -Wl,-Y/home/anisse/dev/qemu-cross/build/lib -Wl,-Y/home/anisse/dev/qemu-cross/build/usr/lib -Wl,-rpath-link,/home/anisse/dev/qemu-cross/build/lib -Wl,-rpath-link,/home/anisse/dev/qemu-cross/build/usr/lib" \ +PKG_CONFIG=pkg-config \ +PKG_CONFIG_LIBDIR="/home/anisse/dev/qemu-cross/build/usr/lib/pkgconfig" \ +PKG_CONFIG_SYSROOT_DIR="/home/anisse/dev/qemu-cross/build" \ +./configure $(cat ../features) --enable-vnc --enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --target-list=aarch64-softmmu --cross-prefix=/opt/toolchains/aarch64-musl-1.2.2-gcc-10.2.0-binutils-2.36-gdb-7.12.1-1/bin/aarch64-linux-musl- + +And the content of the ./features file: + +--enable-system --disable-user --disable-linux-user --disable-bsd-user --disable-docs --disable-guest-agent --disable-guest-agent-msi --enable-pie --disable-modules --disable-module-upgrades --disable-debug-tcg --disable-debug-info --disable-sparse --disable-safe-stack --disable-gnutls --disable-nettle --disable-gcrypt --disable-auth-pam --disable-sdl --disable-sdl-image --disable-gtk --disable-vte --disable-curses --disable-iconv --enable-vnc --enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --disable-cocoa --disable-virtfs --disable-virtiofsd --disable-libudev --disable-mpath --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-curl --enable-membarrier --enable-fdt --enable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-pvrdma --disable-vde --disable-netmap --disable-linux-aio --disable-linux-io-uring --disable-cap-ng --disable-attr --enable-vhost-net --enable-vhost-vsock --enable-vhost-scsi --enable-vhost-crypto --enable-vhost-kernel --enable-vhost-user --disable-vhost-user-blk-server --disable-vhost-vdpa --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-u2f --enable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-lzfse --disable-zstd --disable-seccomp --disable-coroutine-pool --disable-glusterfs --disable-tpm --disable-libssh --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-avx2 --disable-avx512f --disable-replication --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --enable-tools --disable-bochs --disable-cloop --disable-dmg --enable-qcow1 --enable-vdi --disable-vvfat --disable-qed --disable-parallels --disable-sheepdog --enable-crypto-afalg --disable-capstone --disable-debug-mutex --disable-libpmem --disable-xkbcommon --disable-rng-none --disable-libdaxctl + + +Sorry, this is the "fixed" version, but you get the idea of how I invoke it. sasl.h is present in +/home/anisse/dev/qemu-cross/build/usr/include/sasl/sasl.h ; this path is passed through -isystem. + +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/105/KVM/1926952 b/results/classifier/105/KVM/1926952 new file mode 100644 index 00000000..59dd87ae --- /dev/null +++ b/results/classifier/105/KVM/1926952 @@ -0,0 +1,239 @@ +KVM: 0.656 +graphic: 0.597 +vnc: 0.579 +other: 0.565 +semantic: 0.553 +device: 0.517 +instruction: 0.511 +mistranslation: 0.505 +network: 0.474 +boot: 0.468 +assembly: 0.424 +socket: 0.390 + +SPICE support broken with 6.0 + +Using latest relase 6.0.0 while using Intel GVT-G DMA-BUF and SPICE for usb redirection Qemu won't start: + +qemu-system-x86_64: The console requires display DMABUF support. + +However just patching ui/console.c: + +if (flags & GRAPHIC_FLAGS_DMABUF && + !displaychangelistener_has_dmabuf(dcl)) { + error_setg(errp, "The console requires display DMABUF support."); + return false; +} + +to always return true for dmabuf part works just fine: + +if (flags & GRAPHIC_FLAGS_DMABUF && + !displaychangelistener_has_dmabuf(dcl)) { + error_setg(errp, "The console requires display DMABUF support."); + return true; +} + +This behavior wasn't in qemu 5.x version. + +To reproduce this bug need to use: + +/usr/bin/qemu-system-x86_64 \ +-machine q35 \ +-enable-kvm \ +-no-user-config \ +-nodefaults \ +-no-hpet \ +-display gtk,gl=on \ +-device pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +-device vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci0000:00/0000:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2 \ +-spice port=5900,addr=127.0.0.1,disable-ticketing=on + +Also just removing spice part makes it bootable: +-spice port=5900,addr=127.0.0.1,disable-ticketing=on + + +Hi + +On Mon, May 3, 2021 at 4:07 PM Firecode95 <email address hidden> +wrote: + +> Also just removing spice part makes it bootable: +> -spice port=5900,addr=127.0.0.1,disable-ticketing=on +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1926952 +> +> Title: +> SPICE support broken with 6.0 +> +> Status in QEMU: +> New +> +> Bug description: +> Using latest relase 6.0.0 while using Intel GVT-G DMA-BUF and SPICE +> for usb redirection Qemu won't start: +> +> qemu-system-x86_64: The console requires display DMABUF support. +> +> However just patching ui/console.c: +> +> if (flags & GRAPHIC_FLAGS_DMABUF && +> !displaychangelistener_has_dmabuf(dcl)) { +> error_setg(errp, "The console requires display DMABUF support."); +> return false; +> } +> +> to always return true for dmabuf part works just fine: +> +> if (flags & GRAPHIC_FLAGS_DMABUF && +> !displaychangelistener_has_dmabuf(dcl)) { +> error_setg(errp, "The console requires display DMABUF support."); +> return true; +> } +> +> This behavior wasn't in qemu 5.x version. +> +> To reproduce this bug need to use: +> +> /usr/bin/qemu-system-x86_64 \ +> -machine q35 \ +> -enable-kvm \ +> -no-user-config \ +> -nodefaults \ +> -no-hpet \ +> -display gtk,gl=on \ +> -device +> pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 +> \ +> -device +> vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci0000:00/0000:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2 +> \ +> -spice port=5900,addr=127.0.0.1,disable-ticketing=on +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1926952/+subscriptions +> +> + +Did you actually get the dmabuf update displayed over spice? If not, then +it is not a bug, it's a bug fix :) But I might be missing something.. I +don't see how this could happen without egl-headless though. + + +-- +Marc-André Lureau + + +After launching qemu I have qemu display from intel gpu(gvt-g), terminal output of launched script. After that launching in terminal separate instance remote-viewer for spice to passthru usb devices - spice dislay is blank, that was also in 5.x versions, but just now to get spice running I need to patch check to always return true. As I understood I have egl-headless window as there is fully aclerated guest video output: + +Full comand that I am running is as follow: + +DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )" +cp /home/firecode95/.config/pulse/cookie /root/.config/pulse/cookie +/usr/bin/qemu-system-x86_64 \ +-name guest=windows10 \ +-machine q35,accel=kvm,vmport=off,kernel_irqchip=on \ +-cpu host,hv_time,kvm=off,hv-relaxed,hv-vapic,kvm-asyncpf-int,topoext,host-cache-info=on,check,hv_stimer,hv_synic,hv_vpindex,-hypervisor,hv_spinlocks=0x1fff,hv_vapic \ +-enable-kvm \ +-drive if=pflash,format=raw,readonly=on,file=$DIR/OVMF_CODE.fd \ +-drive if=pflash,format=raw,file=$DIR/OVMF_VARS.fd \ +-smp 12,sockets=1,dies=1,cores=6,threads=2 \ +-mem-path /dev/hugepages \ +-m 8G \ +-uuid e7d44285-507b-48da-bfe2-2eba415016bd \ +-no-user-config \ +-nodefaults \ +-no-hpet \ +-rtc base=localtime \ +-global PIIX4_PM.disable_s3=0 \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-global isa-debugcon.iobase=0x402 \ +-debugcon file:/tmp/windows_10.ovmf.log \ +-monitor stdio \ +-boot menu=on,strict=on \ +-device pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ +-device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \ +-device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \ +-device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \ +-device i82801b11-bridge,id=pci.7,bus=pcie.0,addr=0x1e \ +-device pci-bridge,chassis_nr=8,id=pci.8,bus=pci.7,addr=0x0 \ +-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \ +-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d \ +-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \ +-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +-object iothread,id=iothread0 \ +-device virtio-scsi-pci,iothread=iothread0,num_queues=8,id=scsi0,bus=pcie.0,addr=0x3 \ +-drive file=$DIR/virtio-win-0.1.185.iso,media=cdrom,bus=2 \ +-drive if=none,id=hd1,file=$DIR/$1.qcow2,format=qcow2,cache.direct=on,discard=unmap,aio=threads \ +-device scsi-hd,drive=hd1 \ +-object input-linux,id=kbd1,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=on,repeat=on \ +-acpitable file=$DIR/SSDT1.dat \ +-msg timestamp=on \ +-netdev type=tap,id=net0,ifname=tap1,script=$DIR/tap_ifup,downscript=$DIR/tap_ifdown,vhost=on \ +-device virtio-net-pci,netdev=net0,mac=52:54:BE:EF:A1:67,bus=pci.5,addr=0x0 \ +-spice port=5902,addr=127.0.0.1,disable-ticketing=on \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-display gtk,gl=on \ +-device vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci0000:00/0000:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2 \ +-device vfio-pci,host=0000:01:00.0,id=hostdev0,bus=pci.1,multifunction=on,addr=0x0,x-pci-sub-vendor-id=0x17aa,x-pci-sub-device-id=0x39fd \ +-device vfio-pci,host=0000:01:00.1,id=hostdev1,bus=pci.1,addr=0x0.0x1 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-chardev spicevmc,id=charredir0,name=usbredir \ +-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 \ +-chardev spicevmc,id=charredir1,name=usbredir \ +-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 \ +-chardev spicevmc,id=charredir2,name=usbredir \ +-device usb-redir,chardev=charredir2,id=redir2,bus=usb.0,port=3 \ +-device ich9-intel-hda \ +-device hda-micro,audiodev=hda \ +-audiodev pa,id=hda,server=/run/user/1000/pulse/native \ +-device usb-host,hostbus=1,hostport=12 + +> launching in terminal separate instance remote-viewer for spice to passthru usb devices - spice dislay is blank, that was also in 5.x versions, + +That was really a hack. I mean, Spice client shouldn't have a blank display. You shouldn't have to run both qemu display and remote-viewer. What you wanted actually is usb redirection with qemu, or you should simply use spice with gl=on to enable the dmabuf support. In the meantime, you could patch qemu to keep your hack solution "working". + +Btw, we are moving to gitlab for bug tracking (https://gitlab.com/qemu-project/qemu). + +But is there any option to dynamically add/remove usb devices like from spice client to vm that is powered up without using spice? As far I have found there is no such option. + +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/105/KVM/1936 b/results/classifier/105/KVM/1936 new file mode 100644 index 00000000..a9c9616e --- /dev/null +++ b/results/classifier/105/KVM/1936 @@ -0,0 +1,14 @@ +KVM: 0.956 +instruction: 0.924 +device: 0.858 +mistranslation: 0.606 +semantic: 0.549 +graphic: 0.363 +boot: 0.309 +network: 0.285 +other: 0.280 +assembly: 0.100 +socket: 0.087 +vnc: 0.056 + +Pass file descriptor to /dev/kvm device node? diff --git a/results/classifier/105/KVM/1941 b/results/classifier/105/KVM/1941 new file mode 100644 index 00000000..a766b454 --- /dev/null +++ b/results/classifier/105/KVM/1941 @@ -0,0 +1,115 @@ +KVM: 0.943 +graphic: 0.942 +other: 0.935 +semantic: 0.908 +instruction: 0.901 +vnc: 0.885 +device: 0.881 +assembly: 0.880 +mistranslation: 0.863 +boot: 0.861 +network: 0.844 +socket: 0.840 + +ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values +Description of problem: +The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. + +Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): +``` +xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {0, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} +xvcvspuxds ({1, 2, nan, nan}) = {0, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} + +xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {0, 0} +``` + +Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): +``` +xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {2, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} +xvcvspuxds ({1, 2, nan, nan}) = {2, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} +xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} +xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} + +xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {1, 0} +``` +Steps to reproduce: +1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` +2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le +3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. +Additional information: +Attachments: +- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) +- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 +- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/105/KVM/1967814 b/results/classifier/105/KVM/1967814 new file mode 100644 index 00000000..90f012d2 --- /dev/null +++ b/results/classifier/105/KVM/1967814 @@ -0,0 +1,438 @@ +KVM: 0.889 +graphic: 0.863 +assembly: 0.859 +other: 0.857 +vnc: 0.853 +network: 0.840 +instruction: 0.839 +boot: 0.839 +socket: 0.835 +semantic: 0.823 +device: 0.822 +mistranslation: 0.746 + +Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path. + +== Comment: #63 - Halil Pasic <email address hidden> - 2022-03-28 17:33:34 == +I'm pretty confident I've figured out what is going on. + +From the guest side, the decision whether the SCSI command was completed successfully or not comes down to looking at the sense data. Prior to commit +a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers."), we don't +build sense data as a response to seeing a host status presented by the host SCSI stack (e.g. kernel). + +Thus when the kernel tells us that a given SCSI command did not get completed via +SCSI_HOST_TRANSPORT_DISRUPTED or SCSI_HOST_NO_LUN, we end up fooling the guest into believing that the command completed successfully. + +The guest kernel, and especially virtio and multipath are at no fault (AFAIU). Given these facts, it isn't all that surprising, that we end up with corruptions. + +All we have to do is do backports for QEMU (when necessary). I didn't investigate vhost-scsi -- my guess is, that it ain't affected. + +How do we want to handle the back-ports? + +== Comment: #66 - Halil Pasic <email address hidden> - 2022-04-04 05:36:33 == +This is a proposed backport containing 7 patches in mbox format. I tried to pick patches sanely, and all I had to do was basically resolving merge conflicts. + +I have to admit I have no extensive experience in doing such invasive backports, and my knowledge of the QEMU SCSI stack is very limited. I would be happy if the Ubuntu folks would have a good look at this, and if possible improve on it. + +Default Comment by Bridge + +Default Comment by Bridge + +Changing the affected package from "linux (Ubuntu)" (kernel) to "qemu (Ubuntu)" as affected package, since the attached patch set is for qemu. + +List of original commits and the version they were in: + +v5.2.0 +commit 3b12a7fd39307017c8968b8d05986a63b33752b5 +Author: Paolo Bonzini <email address hidden> +Date: Thu Nov 12 10:52:04 2020 +0100 + scsi-disk: convert more errno values back to SCSI statuses + +v6.0.0 +commit f95f61c2c9618fae7d8ea4c1d63e7416884bad52 +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 13:14:07 2021 +0100 + scsi-disk: move scsi_handle_rw_error earlier + +v6.0.0 +commit d7a84021db8eeddcd5d24ab591a1434763caff6c +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 16:30:09 2021 +0100 + scsi: introduce scsi_sense_from_errno() + +v6.0.0 +commit f63c68bc0f514694a958b2e84a204b7792d28b17 +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 18:59:36 2021 +0100 + scsi-disk: pass SCSI status to scsi_handle_rw_error + +v6.0.0 +commit 41af878b96582fc8c83303ab8921e40468403702 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:38 2020 +0100 + scsi: Rename linux-specific SG_ERR codes to generic SCSI_HOST error codes + +v6.0.0 +commit db66a15cb80f09da24a5311a3f3b8f0c1835bf71 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:39 2020 +0100 + scsi: Add mapping for generic SCSI_HOST status to sense codes + +v6.0.0 +commit a108557bbff8a3f44233982f015f996426411be8 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:40 2020 +0100 + scsi: inline sg_io_sense_from_errno() into the callers. + +Thereby indeed this is only for Focal. +Sorry, but analyzing the details will take more time... + +I can confirm that just on the patch-level only two need backporting, the rest applies as is and I have regenerated them to match the packaging requirements. The backport-adaptations themselves are minimal. + +From the content I guess it is complex enough that nobody can be fully sure. +I'm still reading it ... + +Until then a few questions: +- I wonder if we'd also want/need dc293f6 "scsi: fix sense code for EREMOTEIO" (to ensure this kind of ioerror gets to the guest as well) - what do you think? +- I also wondered about 424740d "scsi-disk: do not complete requests early for rerror/werror=ignore" but we do not have 40dce4ee applied so that should be ok + +I'm done reading and while a complex subsystem and a bunch of changes they individually all seem sane to me (although a108557b could have side effects that are hard to spot). + +For SRU considerations I think this includes potential change of behavior of formerly silently ignored errors now becoming visible (or with more detail) to the guest. But IMHO silently hiding I/O errors is asking for problems and data corruption (just as you've found it=, while reporting them is correct. + +I'll later build a PPA for your testing as you seem to have a testcase with Disktest on your side that can reproduce the issue that made you aware. + +Prepared +PPA: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1967814-scsi-error-handling/+packages +MP: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/418636 + +Let us see if one builds and tests fine and the other gets positive review feedback. + +------- Comment From <email address hidden> 2022-04-06 09:24 EDT------- +(In reply to comment #76) +> I can confirm that just on the patch-level only two need backporting, the +> rest applies as is and I have regenerated them to match the packaging +> requirements. The backport-adaptations themselves are minimal. +> +> From the content I guess it is complex enough that nobody can be fully sure. +> I'm still reading it ... +> +> Until then a few questions: +> - I wonder if we'd also want/need dc293f6 "scsi: fix sense code for +> EREMOTEIO" (to ensure this kind of ioerror gets to the guest as well) - what +> do you think? +> - I also wondered about 424740d "scsi-disk: do not complete requests early +> for rerror/werror=ignore" but we do not have 40dce4ee applied so that should +> be ok + +I have nothing against including those. I was under the impression that a minimal fix is desired, and my tests indicate that dose patches are not strictly necessary. + +Generally I think that those are good patches, and having them is better than not having them. But then I hope most of the patches are good patches, and obviously backporting all the good patches is not very practicable -- hence the principle of minimality. + +It is just my two cents. My understanding of SCSI is quite poor. + +You are right for a general stance of SRU minimality + +But this case felt like fixing 7/8 of a single whole. +And while indeed your case didn't need this one more fix someone else would and we touch this code anyway. Vice versa all tests since this is upstream is done with it applied - so the coverage of the code with this added is better than without - so we also avoid unexpected side effects. +OTOH We would not fix something totally else like something in virtio as part of this, no matter how reasonable that patch might look like. + +Let me know if you had time to push the PPA through your testing. + +------- Comment From <email address hidden> 2022-04-07 18:42 EDT------- +(In reply to comment #80) +> Let me know if you had time to push the PPA through your testing. + +Pulled the PPA + +root@ilzlnx3:~# apt info qemu +Package: qemu +Version: 1:4.2-3ubuntu6.22~focalppa1 + +I triggered a path failure from the host and saw the faulty paths on the guest but no data miscompares (first time I've ever seen it not having miscompares at the first try). +Recovered and tried again, this time I did got the miscompares, I captured the DBGINFO and sosreport, let me know if something else is needed. + +********** EXPECTED (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: 1243520, Offset: 5) ********** +00000000 00 00 00 00 00 12 F9 80 00 00 00 00 00 00 00 01 ................ +00000010 00 00 00 00 62 4F 60 1C 00 00 00 00 00 00 06 EB ....bO`......... +00000020 69 6C 7A 6C 6E 78 33 67 31 00 00 00 00 00 00 00 ilzlnx3g1....... +00000030 2F 66 63 2F 6D 61 70 70 65 72 2F 73 63 73 69 5F /fc/mapper/scsi_ +00000040 33 32 47 5F 64 31 5F 69 6C 73 64 39 38 34 30 6C 32G_d1_ilsd9840l + +********** ACTUAL (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: 1243520, Offset: 5) ********** +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + + +------- Comment (attachment only) From <email address hidden> 2022-04-07 18:43 EDT------- + + + +------- Comment (attachment only) From <email address hidden> 2022-04-07 18:44 EDT------- + + +------- Comment From <email address hidden> 2022-04-08 05:13 EDT------- +(In reply to comment #81) +> (In reply to comment #80) +> > Let me know if you had time to push the PPA through your testing. +> +> Pulled the PPA +> +> root@ilzlnx3:~# apt info qemu +> Package: qemu +> Version: 1:4.2-3ubuntu6.22~focalppa1 +> +> I triggered a path failure from the host and saw the faulty paths on the +> guest but no data miscompares (first time I've ever seen it not having +> miscompares at the first try). +> Recovered and tried again, this time I did got the miscompares, I captured +> the DBGINFO and sosreport, let me know if something else is needed. +> +> ********** EXPECTED (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: +> 1243520, Offset: 5) ********** +> 00000000 00 00 00 00 00 12 F9 80 00 00 00 00 00 00 00 01 +> ................ +> 00000010 00 00 00 00 62 4F 60 1C 00 00 00 00 00 00 06 EB +> ....bO`......... +> 00000020 69 6C 7A 6C 6E 78 33 67 31 00 00 00 00 00 00 00 +> ilzlnx3g1....... +> 00000030 2F 66 63 2F 6D 61 70 70 65 72 2F 73 63 73 69 5F +> /fc/mapper/scsi_ +> 00000040 33 32 47 5F 64 31 5F 69 6C 73 64 39 38 34 30 6C +> 32G_d1_ilsd9840l +> +> ********** ACTUAL (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: +> 1243520, Offset: 5) ********** +> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ + +That is very bad news! :( + +I was not able to trigger the problem with the patched qemu. I will try harder, but if I can't trigger the problem it becomes very difficult for me to work on it. + +------- Comment From <email address hidden> 2022-04-08 05:20 EDT------- +(In reply to comment #81) +> (In reply to comment #80) +> > Let me know if you had time to push the PPA through your testing. +> +> Pulled the PPA +> +> root@ilzlnx3:~# apt info qemu +> Package: qemu +> Version: 1:4.2-3ubuntu6.22~focalppa1 +> +> I triggered a path failure from the host and saw the faulty paths on the +> guest but no data miscompares (first time I've ever seen it not having +> miscompares at the first try). +> Recovered and tried again, this time I did got the miscompares, I captured +> the DBGINFO and sosreport, let me know if something else is needed. + +Maybe we are hitting a different case. Maybe not. In the past we used to observe multiple types of miscompares one of which is the all zero, and another one is wrong but still disktest data. + +I'm curious if we see the wrong disktest data type of miscompare with the patched qemu. + +Also I would like to know if the miscompare is still observable after a reboot (i.e. if you destroy and re-start the guest, and then do a manual compare with disktest on the given block (without the write phase). + +Also can I help you install a self-built upstream qemu so we can test with that as well? Maybe we are just missing some more patches. + +Thanks Vanessa for the testing on the PPA! + +@Halil - I'd leave the debugging of the remaining issue to you as while you can't reproduce it yet it still is much closer to you than it is to me :-/ Thanks in advance, let us know what you find. + +In the meantime I have prepared the SRU content and got a PR review, so once we are convinced it is good - or found what we need to change - we should be ready to continue. + +------- Comment From <email address hidden> 2022-04-25 19:20 EDT------- +(In reply to comment #94) +> Thanks Vanessa for the testing on the PPA! +> +> @Halil - I'd leave the debugging of the remaining issue to you as while you +> can't reproduce it yet it still is much closer to you than it is to me :-/ +> Thanks in advance, let us know what you find. +> +> In the meantime I have prepared the SRU content and got a PR review, so once +> we are convinced it is good - or found what we need to change - we should be +> ready to continue. + +I was not testing the PPA you provided properly, I pulled it again and made sure it was installed and running: + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +I ran the error injects for a few hours and no miscompares were encountered. +Thanks @Halil, for bringing the issue to my attention! + +------- Comment From <email address hidden> 2022-04-28 05:22 EDT------- +(In reply to comment #97) +> (In reply to comment #94) +> > Thanks Vanessa for the testing on the PPA! +> > +> > @Halil - I'd leave the debugging of the remaining issue to you as while you +> > can't reproduce it yet it still is much closer to you than it is to me :-/ +> > Thanks in advance, let us know what you find. +> > +> > In the meantime I have prepared the SRU content and got a PR review, so once +> > we are convinced it is good - or found what we need to change - we should be +> > ready to continue. +> +> I was not testing the PPA you provided properly, I pulled it again and made +> sure it was installed and running: +> +> root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +> QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +> +> I ran the error injects for a few hours and no miscompares were encountered. +> Thanks @Halil, for bringing the issue to my attention! + +@Ubuntu: I think we can and should move forward with this. The problem with the +previous test results is, that the qemu from the PPA wasn't installed at all, and thus we ended up just verifying that the old one is still broken. + +I read Vanessas comment like, she the issue is not observed any more with the PPA installed: i.e. the fix works at least for the test-case that used to trigger the problem reliably. @Vanessa: Please correct me if I'm wrong. + +------- Comment From <email address hidden> 2022-04-28 18:36 EDT------- +(In reply to comment #98) +> +> @Ubuntu: I think we can and should move forward with this. The problem with +> the +> previous test results is, that the qemu from the PPA wasn't installed at +> all, and thus we ended up just verifying that the old one is still broken. +> +> I read Vanessas comment like, she the issue is not observed any more with +> the PPA installed: i.e. the fix works at least for the test-case that used +> to trigger the problem reliably. @Vanessa: Please correct me if I'm wrong. + +That is correct, the fix works, no miscompares while doing the test-case I've been using to reproduce this issue (tested for a few hours, no more than 30 seconds in between error injects). + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Following up on some older bugs... +Okay, that means the PPA version of qemu for focal could be successfully verified (no miss-compares). +So I'll change the status back to In Progress ... + +Thanks for the pre-check. +Everything is ready and now uploaded to Focal, there please verify it on the real build once accepted by the SRU team. + +Hello bugproxy, 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.22 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. + +I've accepted this, and I agree that this is a good candidate for testing in proposed for longer than 7 days; I'll do so after at least 14 days, so double the normal soak time. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.22) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +ubuntu-image/1.11+20.04ubuntu1 (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! + + +That was a flaky test, resolved by now. + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.23 + +--------------- +qemu (1:4.2-3ubuntu6.23) focal-security; urgency=medium + + * SECURITY UPDATE: heap overflow in floppy disk emulator + - debian/patches/CVE-2021-3507.patch: prevent end-of-track overrun in + hw/block/fdc.c. + - CVE-2021-3507 + * SECURITY UPDATE: integer overflow in QXL display device emulation + - debian/patches/CVE-2021-4206.patch: check width and height in + hw/display/qxl-render.c, hw/display/vmware_vga.c, ui/cursor.c. + - CVE-2021-4206 + * SECURITY UPDATE: heap overflow in QXL display device emulation + - debian/patches/CVE-2021-4207.patch: fix race condition in qxl_cursor + in hw/display/qxl-render.c. + - CVE-2021-4207 + * SECURITY UPDATE: memory leakage in virtio-net device + - debian/patches/CVE-2022-26353.patch: fix map leaking on error during + receive in hw/net/virtio-net.c. + - CVE-2022-26353 + * SECURITY UPDATE: memory leakage in vhost-vsock device + - debian/patches/CVE-2022-26354.patch: detach the virqueue element in + case of error in hw/virtio/vhost-vsock.c. + - CVE-2022-26354 + + -- Marc Deslauriers <email address hidden> Thu, 09 Jun 2022 11:35:04 -0400 + +------- Comment From <email address hidden> 2022-06-21 11:20 EDT------- +(In reply to comment #105) +> 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. +> +Tested this fix and it has solved the issue. Tested with the following version: + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Testing performed: +HostSidePortBounce: +1. Run I/O on mapped LUNs +2. Disable one port on host side and wait for 10 minutes +3. Enable the port and wait for 10 minutes +4. Repeat step b and c with the other ports +5. Check I/O tool logs + +Passed. No miscompares or error logs. + +Switch Reboot: +1. Start IO on mapped LUNs +2. Reload brocade/cisco switch and wait for 5 minutes after switch online for host recovery +3. Check I/O tool logs + +Passed. No miscompares or error logs. + +SVC Node reset: +1. Run I/O on mapped LUNs +2. Execute anode reset warm start script against the cluster. +3. Check both I/O logs and script logs + +Passed. No miscompares or error logs. + +zMpath failover failback +1. Run I/O on mapped LUN +2. Vary off one chpid of a lpar and wait for 60 seconds +3. Vary on the chpid ofthe lpar and wait for 20 minutes +4. Repeat step b and c with the other chpids of the lpar +5. Check logs of I/O tool + +Passed. No miscompares or error logs. + +> Further information regarding the verification process can be found at +> https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in +> advance for helping! + +Thanks for the patience awaiting testing and for all the effort + diff --git a/results/classifier/105/KVM/1977 b/results/classifier/105/KVM/1977 new file mode 100644 index 00000000..4091ef95 --- /dev/null +++ b/results/classifier/105/KVM/1977 @@ -0,0 +1,43 @@ +KVM: 0.675 +graphic: 0.672 +mistranslation: 0.672 +other: 0.659 +instruction: 0.627 +device: 0.583 +assembly: 0.524 +boot: 0.523 +semantic: 0.519 +vnc: 0.498 +network: 0.434 +socket: 0.412 + +MSYS2 build fails with link errors on Window 10 22H2 +Description of problem: +Linking target tests/plugin/libbb.dll fails with undefined references in below attached output +Steps to reproduce: +1. Open MSYS2 build environment on Windows 10 +2. mkdir build && cd build && ../configure --prefix=/home/Admin --enable-sdl --enable-gtk --target-list=arm-softmmu +3. make -j4 +Additional information: +[2300/2631] Linking target tests/plugin/libbb.dll +FAILED: tests/plugin/libbb.dll +"cc" "-m64" "-mcx16" -o tests/plugin/libbb.dll plugins/qemu_plugin_api.lib tests/plugin/libbb.dll.p/bb.c.obj tests/plugin/libbb.dll.p/.._.._contrib_plugins_win32_linker.c.obj "-Wl,--allow-shlib-undefined" "-shared" "-Wl,--start-group" "-Wl,--out-implib=tests/plugin/libbb.dll.a" "-fstack-protector-strong" "-Wl,--no-seh" "-Wl,--nxcompat" "-Wl,--dynamicbase" "-Wl,--high-entropy-va" "-Wl,--warn-common" "C:/msys64/ucrt64/lib/libglib-2.0.dll.a" "C:/msys64/ucrt64/lib/libintl.dll.a" "C:/msys64/ucrt64/lib/libgmodule-2.0.dll.a" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32" "-Wl,--end-group" +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `vcpu_tb_trans': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:84:(.text+0x4f): undefined reference to `__imp_qemu_plugin_tb_n_insns' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:87:(.text+0x62): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:93:(.text+0xba): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `plugin_exit': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:55:(.text+0x1cb): undefined reference to `__imp_qemu_plugin_outs' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:55:(.text+0x204): undefined reference to `__imp_qemu_plugin_outs' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `vcpu_idle': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:66:(.text+0x299): undefined reference to `__imp_qemu_plugin_outs' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `qemu_plugin_install': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:114:(.text+0x2e8): undefined reference to `__imp_qemu_plugin_bool_parse' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:141:(.text+0x3d5): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:142:(.text+0x3ea): undefined reference to `__imp_qemu_plugin_register_atexit_cb' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:138:(.text+0x420): undefined reference to `__imp_qemu_plugin_register_vcpu_idle_cb' +collect2.exe: error: ld returned 1 exit status +[2301/2631] Compiling C object tests/plugin/libempty.dll.p/.._.._contrib_plugins_win32_linker.c.obj +[2302/2631] Compiling C object tests/libtestqapi.a.p/meson-generated_.._test-qapi-visit.c.obj +[2303/2631] Compiling C object tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj +ninja: build stopped: subcommand failed. diff --git a/results/classifier/105/KVM/2041 b/results/classifier/105/KVM/2041 new file mode 100644 index 00000000..8e0db2f3 --- /dev/null +++ b/results/classifier/105/KVM/2041 @@ -0,0 +1,40 @@ +KVM: 0.864 +graphic: 0.739 +network: 0.704 +device: 0.653 +other: 0.595 +mistranslation: 0.530 +instruction: 0.530 +socket: 0.474 +boot: 0.423 +semantic: 0.342 +vnc: 0.288 +assembly: 0.169 + +RISC-V KVM build error with Alpine Linux +Description of problem: +Native build of qemu fails on alpine linux riscv64. +Steps to reproduce: +1. install alpine on riscv or set up a container with qemu-riscv64 +2. build qemu 8.1.3 from source +3. +Additional information: +``` +kvm.c:(.text+0xc50): undefined reference to `strerrorname_np' +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm.c.o: in function `.L0 ': +kvm.c:(.text+0xcda): undefined reference to `strerrorname_np' +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm.c.o: in function `.L111': +kvm.c:(.text+0xd02): undefined reference to `strerrorname_np' +``` + +The `strerrorname_np` is a GNU specific non-portable function (that what _np stands for). This is the only place where it is use in the entire qemu codebase: +``` +$ rg strerrorname_np +target/riscv/kvm/kvm-cpu.c +837: strerrorname_np(errno)); +899: strerrorname_np(errno)); +909: strerrorname_np(errno)); +932: strerrorname_np(errno)); +``` + +Seems like other places uses `strerror(errno)`. diff --git a/results/classifier/105/KVM/2046 b/results/classifier/105/KVM/2046 new file mode 100644 index 00000000..aedc72cf --- /dev/null +++ b/results/classifier/105/KVM/2046 @@ -0,0 +1,14 @@ +KVM: 0.953 +device: 0.857 +network: 0.850 +vnc: 0.625 +socket: 0.606 +graphic: 0.547 +boot: 0.509 +mistranslation: 0.501 +instruction: 0.499 +semantic: 0.362 +other: 0.298 +assembly: 0.061 + +live migration error : qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm diff --git a/results/classifier/105/KVM/2060 b/results/classifier/105/KVM/2060 new file mode 100644 index 00000000..94b5fad4 --- /dev/null +++ b/results/classifier/105/KVM/2060 @@ -0,0 +1,16 @@ +KVM: 0.898 +mistranslation: 0.752 +instruction: 0.740 +device: 0.728 +semantic: 0.722 +other: 0.621 +network: 0.605 +graphic: 0.530 +boot: 0.278 +socket: 0.270 +vnc: 0.204 +assembly: 0.026 + +memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set +Additional information: +i'm using pve-qemu-kvm 8.1.2-6 on 6.5.11-7-pve kernel diff --git a/results/classifier/105/KVM/2071 b/results/classifier/105/KVM/2071 new file mode 100644 index 00000000..e8f51bf4 --- /dev/null +++ b/results/classifier/105/KVM/2071 @@ -0,0 +1,125 @@ +KVM: 0.428 +other: 0.387 +network: 0.363 +device: 0.356 +graphic: 0.355 +semantic: 0.347 +vnc: 0.342 +assembly: 0.339 +instruction: 0.337 +boot: 0.331 +socket: 0.308 +mistranslation: 0.263 + +Segfault when starting a guest with spice configured to listen on a unix socket +Description of problem: +Guest crash immediately when spice is configured to listen on a unix socket. +Steps to reproduce: +1. Configure spice to listen on a unix socket +2. Start the guest +Additional information: +Here's the log when I start the guest: + +``` +[root@localhost ~]# virsh start fedora-waydroid +error: Failed to start domain 'fedora-waydroid' +error: internal error: qemu unexpectedly closed the monitor +``` +Here's the relevant output in journald: + +`SECCOMP auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f7b95459397 code=0x80000000` + +<details><summary>Full journald</summary> + +``` +Jan 04 11:59:03 localhost polkitd[1436]: Registered Authentication Agent for unix-process:17895:5747660 (system bus name :1.160 [/usr/bin/pkttyagent --process 17895 --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) +Jan 04 11:59:03 localhost audit[1595]: VIRT_MACHINE_ID pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 vm-ctx=+107:+107 img-ctx=+107:+107 model=dac exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter +Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter +Jan 04 11:59:03 localhost polkitd[1436]: Unregistered Authentication Agent for unix-process:17895:5747660 (system bus name :1.160, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) +Jan 04 11:59:03 localhost audit: ANOM_PROMISCUOUS dev=vnet12 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 net=52:54:00:72:c3:92 path="/dev/net/tun" rdev=0A:C8 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 net=52:54:00:72:c3:92 path="/dev/vhost-net" rdev=0A:EE exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2422] manager: (vnet12): new Tun device (/org/freedesktop/NetworkManager/Devices/19) +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered blocking state +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state +Jan 04 11:59:03 localhost kernel: vnet12: entered allmulticast mode +Jan 04 11:59:03 localhost kernel: vnet12: entered promiscuous mode +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered blocking state +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered forwarding state +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2468] device (vnet12): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2470] device (vnet12): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2473] device (vnet12): Activation: starting connection 'vnet12' (abcdefgh-ijkl-mnop-qrst-uvwx12345679) +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2478] device (vnet12): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2479] device (vnet12): state change: prepare -> config (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2480] device (vnet12): state change: config -> ip-config (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2480] device (br-dmz): bridge port vnet12 was attached +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2480] device (vnet12): Activation: connection 'vnet12' enslaved, continuing activation +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2481] device (vnet12): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost systemd-machined[1368]: New machine qemu-10-fedora-waydroid. +Jan 04 11:59:03 localhost systemd[1]: Started machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope - Virtual Machine qemu-10-fedora-waydroid. +Jan 04 11:59:03 localhost systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service... +Jan 04 11:59:03 localhost audit: BPF prog-id=112 op=LOAD +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=deny vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=all exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/null" rdev=01:03 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/full" rdev=01:07 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/zero" rdev=01:05 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/random" rdev=01:08 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/urandom" rdev=01:09 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/ptmx" rdev=05:02 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/kvm" rdev=0A:E8 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=major category=pty maj=88 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/dri/by-path/pci-0000:00:02.0-render" rdev=E2:80 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 cgroup="/sys/fs/cgroup/machine.slice/machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope/" class=path path="/dev/urandom" rdev=01:09 acl=rw exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service. +Jan 04 11:59:03 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2796] device (vnet12): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2797] device (vnet12): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.2799] device (vnet12): Activation: successful, device activated. +Jan 04 11:59:03 localhost systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive. +Jan 04 11:59:03 localhost audit[17930]: SECCOMP auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f7b95459397 code=0x80000000 +Jan 04 11:59:03 localhost audit[17930]: ANOM_ABEND auid=4294967295 uid=107 gid=107 ses=4294967295 pid=17930 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 res=1 +Jan 04 11:59:03 localhost audit: BPF prog-id=113 op=LOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=114 op=LOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=115 op=LOAD +Jan 04 11:59:03 localhost systemd[1]: Started systemd-coredump@3-17978-0.service - Process Core Dump (PID 17978/UID 0). +Jan 04 11:59:03 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-17978-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost systemd-coredump[17980]: Resource limits disable core dumping for process 17930 (qemu-system-x86). +Jan 04 11:59:03 localhost systemd-coredump[17980]: [🡕] Process 17930 (qemu-system-x86) of user 107 terminated abnormally without generating a coredump. +Jan 04 11:59:03 localhost systemd[1]: systemd-coredump@3-17978-0.service: Deactivated successfully. +Jan 04 11:59:03 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@3-17978-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit: ANOM_PROMISCUOUS dev=vnet12 prom=0 old_prom=256 auid=4294967295 uid=107 gid=107 ses=4294967295 +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state +Jan 04 11:59:03 localhost kernel: vnet12 (unregistering): left allmulticast mode +Jan 04 11:59:03 localhost kernel: vnet12 (unregistering): left promiscuous mode +Jan 04 11:59:03 localhost kernel: br-dmz: port 4(vnet12) entered disabled state +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.3895] device (vnet12): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed') +Jan 04 11:59:03 localhost NetworkManager[1338]: <info> [1704394743.3897] device (vnet12): released from master device br-dmz +Jan 04 11:59:03 localhost virtqemud[1595]: Unable to read from monitor: Connection reset by peer +Jan 04 11:59:03 localhost virtqemud[1595]: internal error: qemu unexpectedly closed the monitor +Jan 04 11:59:03 localhost virtqemud[1595]: internal error: process exited while connecting to monitor +Jan 04 11:59:03 localhost virtlogd[1659]: Client hit max requests limit 1. This may result in keep-alive timeouts. Consider tuning the max_client_requests server parameter +Jan 04 11:59:03 localhost virtqemud[1595]: Failed to acquire pid file '/run/libvirt/qemu/swtpm/10-fedora-waydroid-swtpm.pid': Resource temporarily unavailable +Jan 04 11:59:03 localhost systemd[1]: machine-qemu\x2d10\x2dfedora\x2dwaydroid.scope: Deactivated successfully. +Jan 04 11:59:03 localhost systemd-machined[1368]: Machine qemu-10-fedora-waydroid terminated. +Jan 04 11:59:03 localhost audit: BPF prog-id=115 op=UNLOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=114 op=UNLOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=113 op=UNLOAD +Jan 04 11:59:03 localhost audit: BPF prog-id=112 op=UNLOAD +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=disk reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-disk="?" new-disk="/var/lib/libvirt/images/fedora-waydroid.img" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-net="?" new-net="52:54:00:72:c3:92" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 bus=usb device=555342207265646972646576 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 bus=usb device=555342207265646972646576 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=rng reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-rng="?" new-rng="/dev/urandom" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=tpm-emulator reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 device="?" exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=mem reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-mem=0 new-mem=4194304 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_RESOURCE pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=vcpu reason=start vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 old-vcpu=0 new-vcpu=4 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=success' +Jan 04 11:59:03 localhost audit[1595]: VIRT_CONTROL pid=1595 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm op=start reason=booted vm="fedora-waydroid" uuid=abcdefgh-ijkl-mnop-qrst-uvwx12345678 vm-pid=0 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=failed' +``` + +<details> + +For the record I filed a bug earlier in libvirt (https://gitlab.com/libvirt/libvirt/-/issues/573) but I now think it's qemu related. + + +/label ~"kind::Bug" diff --git a/results/classifier/105/KVM/2110 b/results/classifier/105/KVM/2110 new file mode 100644 index 00000000..83dac42e --- /dev/null +++ b/results/classifier/105/KVM/2110 @@ -0,0 +1,24 @@ +KVM: 0.913 +device: 0.897 +graphic: 0.895 +vnc: 0.860 +socket: 0.853 +network: 0.836 +instruction: 0.707 +semantic: 0.696 +boot: 0.559 +mistranslation: 0.443 +assembly: 0.222 +other: 0.210 + +live migrations fail qemu-kvm +Description of problem: +live migrations fail between two identical hosts +``` +2024-01-18T00:16:31.582070Z qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm +2024-01-18T00:16:31.582169Z qemu-kvm: load of migration failed: Invalid argument +2024-01-18 00:16:31.611+0000: shutting down, reason=failed +``` +Additional information: +source log for vm [source.log](/uploads/5816f929a5e543f423bb909a0df23fb7/source.log) +dest log for vm [dest.log](/uploads/a1b6ae02e4c8235536e740b86d16ddd6/dest.log) diff --git a/results/classifier/105/KVM/2165 b/results/classifier/105/KVM/2165 new file mode 100644 index 00000000..daef2d59 --- /dev/null +++ b/results/classifier/105/KVM/2165 @@ -0,0 +1,81 @@ +KVM: 0.527 +mistranslation: 0.522 +other: 0.483 +vnc: 0.468 +graphic: 0.458 +boot: 0.448 +device: 0.439 +instruction: 0.429 +semantic: 0.408 +network: 0.404 +assembly: 0.398 +socket: 0.388 + +m68k: 68000 strict alignment requirements not emulated correctly +Description of problem: +Unaligned accesses should cause an address error on the 68000 but apparently currently don't. +Steps to reproduce: +1. Create a 68000 based QEMU machine to port u-boot/linux +2. Get u-boot/linux working perfectly on your QEMU machine +3. Copy kernel over to your real 68000 hardware +4. Notice that the kernel doesn't work +5. Spend a day adding inline assembly all over the kernel to work out where the real hardware is locking up +6. Find that the issue is probably memmove() being called with an unaligned src pointer: + +C level.. + +``` +Breakpoint 1, memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152 +152 *--sdest = *--ssrc; +(gdb) bt +#0 memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152 +#1 memmove (dest=<optimized out>, src=<optimized out>, n=<optimized out>) at ../arch/m68k/lib/memmove.c:10 +#2 0x000265b6 in record_print_text (r=<optimized out>, syslog=<optimized out>, time=<optimized out>) at ../kernel/printk/printk.c:1472 +#3 0x00027be6 in printk_get_next_message (pmsg=<optimized out>, seq=<optimized out>, is_extended=<optimized out>, may_suppress=<optimized out>) at ../kernel/printk/printk.c:2952 +#4 0x00027e5a in console_emit_next_record (cookie=0, handover=0x1d9e37, con=0x1edf14 <early_con>) at ../kernel/printk/printk.c:3019 +#5 console_flush_all (do_cond_resched=false, next_seq=0x1d9e38, handover=0x1d9e37) at ../kernel/printk/printk.c:3118 +#6 0x00027fc8 in console_unlock () at ../kernel/printk/printk.c:3187 +#7 0x00028a04 in vprintk_emit (facility=0, level=<optimized out>, dev_info=0x0, fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2359 +#8 0x00028a26 in vprintk_default (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2374 +#9 0x00028c22 in vprintk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk_safe.c:45 +#10 0x0019d016 in _printk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n") at ../kernel/printk/printk.c:2384 +#11 0x0002857e in register_console (newcon=<optimized out>) at ../kernel/printk/printk.c:3693 +#12 0x001fbf1e in register_earlycon (match=<optimized out>, buf=0x0) at ../drivers/tty/serial/earlycon.c:161 +#13 setup_earlycon (buf=<optimized out>) at ../drivers/tty/serial/earlycon.c:212 +#14 0x001fbf72 in param_setup_earlycon (buf=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900") at ../drivers/tty/serial/earlycon.c:244 +#15 0x001f1102 in do_early_param (param=0x2009e0 <tmp_cmdline> "earlycon", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", unused=0x1b96c6 "early options", arg=0x0) + at ../init/main.c:744 +#16 0x00017eac in parse_one (handle_unknown=<optimized out>, arg=<optimized out>, max_level=<optimized out>, min_level=<optimized out>, num_params=<optimized out>, params=<optimized out>, + doing=0x1b96c6 "early options", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", param=0x2009e0 <tmp_cmdline> "earlycon") at ../kernel/params.c:154 +#17 parse_args (doing=<optimized out>, args=0x2009fe <tmp_cmdline+30> "console=ttyDB0 root=/dev/mmcblk0p2 rootfstype=squashfs rootwait", params=<optimized out>, num=<optimized out>, + min_level=<optimized out>, max_level=<optimized out>, arg=<optimized out>, unknown=<optimized out>) at ../kernel/params.c:189 +#18 0x001f13ea in parse_early_options (cmdline=0x2009e0 <tmp_cmdline> "earlycon") at ../init/main.c:754 +#19 0x001f1420 in parse_early_param () at ../init/main.c:769 +#20 0x001f1570 in start_kernel () at ../init/main.c:908 +#21 0x000004b8 in _clear_bss () at ../arch/m68k/dt/head.S:95 +#22 0x00000000 in ?? () +``` + +Asm level: + +``` +152 *--sdest = *--ssrc; + 0x0019bed8 <+324>: movel %a1,%d2 + 0x0019beda <+326>: subql #2,%d2 + 0x0019bedc <+328>: movel %a2,%d1 + 0x0019bede <+330>: subql #2,%d1 +=> 0x0019bee0 <+332>: movew %a1@(-2),%a2@(-2) +``` + +This is a word store so needs to be aligned but a1 isn't aligned so we should get an address error: + +``` +(gdb) print/x $a1 +$3 = 0x2059df +(gdb) print/x $a2 +$4 = 0x2059ee +``` + + +7. Check QEMU source code to work out why it doesn't crash the cpu at the same place. +8. Notice it doesn't seem to check the alignment. diff --git a/results/classifier/105/KVM/2265 b/results/classifier/105/KVM/2265 new file mode 100644 index 00000000..d3f54417 --- /dev/null +++ b/results/classifier/105/KVM/2265 @@ -0,0 +1,61 @@ +KVM: 0.840 +vnc: 0.831 +mistranslation: 0.827 +other: 0.802 +graphic: 0.798 +semantic: 0.729 +device: 0.720 +socket: 0.718 +assembly: 0.707 +network: 0.702 +instruction: 0.699 +boot: 0.695 + +qemu-system-x86_64 crash creating snapshot +Description of problem: +I'm facing a crash in qemu-system-x86_64.\ +I crash because bs->children.lh_first is null and QLIST_NEXT try dereference the pointer. It triggers a SIGSEGV\ +The manner to reproduce is too complex to give on gitlab and the version is not recent. (I reproduce also with 7.1)\ + +here is the stack: + +(gdb) p bs->children\ +$1 = {lh_first = 0x0}\ +(gdb)\ +(gdb) p child\ +$2 = (BdrvChild *) 0x0\ +(gdb)\ + if (bs->implicit) {\ + /* For implicit nodes, just copy everything from the single child */\ + child = QLIST_FIRST(&bs->children);\ +----->> assert(QLIST_NEXT(child, next) == NULL);\ + pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),\ + + +#0 bdrv_refresh_filename (bs=0x562927927000) at ../qemu-6.2.0/block.c:7525\ +#1 0x000056292527dd97 in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x562927927000, flat=flat@entry=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block/qapi.c:58\ +#2 0x00005629252470c0 in bdrv_named_nodes_list (flat=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block.c:5863\ +#3 0x000056292523da7e in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/blockdev.c:2935\ +#4 0x0000562925301ebd in qmp_marshal_query_named_block_nodes (args=<optimized out>, ret=0x7fc833c83e88, errp=0x7fc833c83e80) at qapi/qapi-commands-block-core.c:423\ +#5 0x0000562925344129 in do_qmp_dispatch_bh (opaque=0x7fc833c83e90) at ../qemu-6.2.0/qapi/qmp-dispatch.c:129 +#6 0x000056292535ecf5 in aio_bh_call (bh=0x5629295ab560) at ../qemu-6.2.0/util/async.c:141\ +#7 aio_bh_poll (ctx=ctx@entry=0x5629276c93e0) at ../qemu-6.2.0/util/async.c:169\ +#8 0x000056292534cf9e in aio_dispatch (ctx=0x5629276c93e0) at ../qemu-6.2.0/util/aio-posix.c:381\ +#9 0x000056292535eb9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311\ +#10 0x00007fc8351cafee in g_match_info_fetch_pos () from /lib/x86_64-linux-gnu/libglib-2.0.so.0\ +#11 0x00007fc800000000 in ?? ()\ +#12 0x000003a05cb8b408 in ?? ()\ +#13 0x0000000000000000 in ?? ()\ + +The case lh_first = 0x0 seems to be common, but never when bs->implicit is true. bs->implicit seems to be switch to true by another thread.\ +Because the qemu version and the system are too old, I'm not expecting a patch, I'm just requesting an opinion.\ + +I fixed the problem by just doing:\ +child = QLIST_FIRST(&bs->children);\ +if (bs->implicit && (child != NULL)) {\ + assert(QLIST_NEXT(child, next) == NULL);\ + ....\ +}\ +I don't have the qemu knowledge to evaluate it and consequences.\ +Is there anyone who have any idea ?\ +Thank you very much.\ diff --git a/results/classifier/105/KVM/2313 b/results/classifier/105/KVM/2313 new file mode 100644 index 00000000..4237f40d --- /dev/null +++ b/results/classifier/105/KVM/2313 @@ -0,0 +1,30 @@ +KVM: 0.982 +device: 0.705 +graphic: 0.685 +semantic: 0.583 +instruction: 0.502 +vnc: 0.469 +other: 0.403 +network: 0.389 +socket: 0.369 +boot: 0.362 +mistranslation: 0.290 +assembly: 0.082 + +RISC-V KVM strerrorname_np regression breaks build on Alpine Linux +Description of problem: +Build from source fails on Alpine Linux due to the use of the non-portable `strerrorname_np`: +``` +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_realize': +kvm-cpu.c:(.text+0x538): undefined reference to `strerrorname_np' +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_instance_init': +kvm-cpu.c:(.text+0x1244): undefined reference to `strerrorname_np' +``` +Steps to reproduce: +1. install alpine linux on a riscv64 machine +2. build qemu-9.0.0 from source. +3. +Additional information: +Same problem as https://gitlab.com/qemu-project/qemu/-/issues/2041 + +Re-introduced with d4ff3da8f45c52670941c6e1b94e771d69d887e9 and 0d71f0a34938a6ac11953ae3dbec40113d2838a1 diff --git a/results/classifier/105/KVM/2321 b/results/classifier/105/KVM/2321 new file mode 100644 index 00000000..a616b9e1 --- /dev/null +++ b/results/classifier/105/KVM/2321 @@ -0,0 +1,53 @@ +KVM: 0.876 +graphic: 0.855 +other: 0.846 +vnc: 0.811 +instruction: 0.810 +semantic: 0.794 +mistranslation: 0.794 +device: 0.788 +assembly: 0.779 +socket: 0.765 +boot: 0.721 +network: 0.714 + +Segfault when hibernating a KVM VM with QEMU 8.2.3 +Description of problem: +Attempting to hibernate the machine crashes QEMU. +Steps to reproduce: +This involves Nix, please tell me if you want a reproducer that doesn't. + +1. nix build github:NixOS/nixpkgs#nixosTests.hibernate.driver +2. ./result/bin/nixos-test-driver +3. Observe crash +Additional information: +Backtrace: + +``` +#0 kvm_virtio_pci_vq_vector_release (proxy=0x55bd979fd130, vector=<optimized out>) at ../hw/virtio/virtio-pci.c:834 +#1 kvm_virtio_pci_vector_release_one (proxy=proxy@entry=0x55bd979fd130, queue_no=queue_no@entry=0) at ../hw/virtio/virtio-pci.c:965 +#2 0x000055bd9380c430 in virtio_pci_set_vector (vdev=0x55bd97a05500, proxy=0x55bd979fd130, queue_no=0, old_vector=1, new_vector=65535) + at ../hw/virtio/virtio-pci.c:1445 +#3 0x000055bd939c5490 in memory_region_write_accessor (mr=0x55bd979fdc70, addr=26, value=<optimized out>, size=2, shift=<optimized out>, + mask=<optimized out>, attrs=...) at ../system/memory.c:497 +#4 0x000055bd939c4d56 in access_with_adjusted_size (addr=addr@entry=26, value=value@entry=0x7ff49d1ff3e8, size=size@entry=2, + access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55bd939c5410 <memory_region_write_accessor>, mr=<optimized out>, + attrs=...) at ../system/memory.c:573 +#5 0x000055bd939c5081 in memory_region_dispatch_write (mr=mr@entry=0x55bd979fdc70, addr=addr@entry=26, data=<optimized out>, op=<optimized out>, + attrs=attrs@entry=...) at ../system/memory.c:1528 +#6 0x000055bd939ccb0c in flatview_write_continue (fv=fv@entry=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=..., attrs@entry=..., + ptr=ptr@entry=0x7ff4a082d028, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x55bd979fdc70) at ../system/physmem.c:2714 +#7 0x000055bd939ccd83 in flatview_write (fv=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, + len=len@entry=2) at ../system/physmem.c:2756 +#8 0x000055bd939d0099 in address_space_write (len=2, buf=0x7ff4a082d028, attrs=..., addr=61572651286554, as=0x55bd94a4e720 <address_space_memory>) + at ../system/physmem.c:2863 +#9 address_space_rw (as=0x55bd94a4e720 <address_space_memory>, addr=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, len=2, + is_write=<optimized out>) at ../system/physmem.c:2873 +#10 0x000055bd93a24548 in kvm_cpu_exec (cpu=cpu@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-all.c:2915 +#11 0x000055bd93a25795 in kvm_vcpu_thread_fn (arg=arg@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-accel-ops.c:51 +#12 0x000055bd93bb5fa8 in qemu_thread_start (args=0x55bd96294940) at ../util/qemu-thread-posix.c:541 +#13 0x00007ff4a19fd272 in start_thread (arg=<optimized out>) at pthread_create.c:447 +#14 0x00007ff4a1a78dcc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 +``` + +Bisected to https://gitlab.com/qemu-project/qemu/-/commit/fcbb086ae590e910614fe5b8bf76e264f71ef304, reverting that change seems to make things work again. diff --git a/results/classifier/105/KVM/2325 b/results/classifier/105/KVM/2325 new file mode 100644 index 00000000..b4280111 --- /dev/null +++ b/results/classifier/105/KVM/2325 @@ -0,0 +1,24 @@ +KVM: 0.964 +device: 0.837 +graphic: 0.830 +semantic: 0.625 +instruction: 0.618 +other: 0.470 +vnc: 0.397 +socket: 0.397 +mistranslation: 0.306 +boot: 0.255 +network: 0.168 +assembly: 0.066 + +[Performance Regression] Constant freezes on Alder lake and Raptor lake CPUs. +Description of problem: +Strangely, no logs are recorded. The guest just freezes. It can however be rescued by a simple pause and unpause. + +This issue only happens when using the KVM hypervisor. Other hypervisors are fine. + +This issue does NOT happen when I tested my Intel Core i7 8700K. +Steps to reproduce: +1. Create a basic virtual machine for Windows 11 (Or 10). +2. Run it for about 5 - 30 minutes (Sometimes it happens in 20 seconds or even less). +3. The problem should occur. diff --git a/results/classifier/105/KVM/2334 b/results/classifier/105/KVM/2334 new file mode 100644 index 00000000..b1d75113 --- /dev/null +++ b/results/classifier/105/KVM/2334 @@ -0,0 +1,265 @@ +KVM: 0.794 +vnc: 0.649 +graphic: 0.618 +mistranslation: 0.567 +other: 0.553 +device: 0.515 +boot: 0.449 +assembly: 0.436 +instruction: 0.430 +semantic: 0.383 +socket: 0.307 +network: 0.256 + +[9.0.0] qemu breaks mac os vm +Description of problem: +Mac OS Monterey vm not able to boot after upgrading qemu to v. 9.0.0; no issue with qemu 8.2.2. +This vm is booted with opencore latest version. +The vm is not able to boot, apple logo is displayed on the screen for a bit, then the vm shutdowns, this is quite strange. +I can't see anything useful in the logs. +Changing machine type from q35-9.0 back to 8.2 doesn't solve the issue. +The vm is booted via libvirt (latest version) and it's not a quite "base" vm, it has multiple passthroughs and other things. +Before testing into details and starting to run base vms to see if it boots,maybe someone can see something wrong or maybe someone has the same issue. +Reverting back to qemu 8.2.2 fixes all the issues and the vm is able to boot again. +No issues with a windows 11 vm and with a kali vm. +I can say that it's not a DSDT issue (a problem I was having in the past was related with DSTD), because injecting the DSDT of the vm started from v 8.2.2 doesn't boot it. + +This is the xml of the vm: + +``` +<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <name>Monterey</name> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static' current='28'>32</vcpu> + <vcpus> + <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> + <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/> + <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> + <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> + <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> + <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> + <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/> + <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/> + <vcpu id='8' enabled='yes' hotpluggable='yes' order='9'/> + <vcpu id='9' enabled='yes' hotpluggable='yes' order='10'/> + <vcpu id='10' enabled='yes' hotpluggable='yes' order='11'/> + <vcpu id='11' enabled='yes' hotpluggable='yes' order='12'/> + <vcpu id='12' enabled='yes' hotpluggable='yes' order='13'/> + <vcpu id='13' enabled='yes' hotpluggable='yes' order='14'/> + <vcpu id='14' enabled='yes' hotpluggable='yes' order='15'/> + <vcpu id='15' enabled='yes' hotpluggable='yes' order='16'/> + <vcpu id='16' enabled='yes' hotpluggable='yes' order='17'/> + <vcpu id='17' enabled='yes' hotpluggable='yes' order='18'/> + <vcpu id='18' enabled='yes' hotpluggable='yes' order='19'/> + <vcpu id='19' enabled='yes' hotpluggable='yes' order='20'/> + <vcpu id='20' enabled='yes' hotpluggable='yes' order='21'/> + <vcpu id='21' enabled='yes' hotpluggable='yes' order='22'/> + <vcpu id='22' enabled='yes' hotpluggable='yes' order='23'/> + <vcpu id='23' enabled='yes' hotpluggable='yes' order='24'/> + <vcpu id='24' enabled='yes' hotpluggable='yes' order='25'/> + <vcpu id='25' enabled='yes' hotpluggable='yes' order='26'/> + <vcpu id='26' enabled='yes' hotpluggable='yes' order='27'/> + <vcpu id='27' enabled='yes' hotpluggable='yes' order='28'/> + <vcpu id='28' enabled='no' hotpluggable='yes'/> + <vcpu id='29' enabled='no' hotpluggable='yes'/> + <vcpu id='30' enabled='no' hotpluggable='yes'/> + <vcpu id='31' enabled='no' hotpluggable='yes'/> + </vcpus> + <iothreads>2</iothreads> + <iothreadids> + <iothread id='1'/> + <iothread id='2'/> + </iothreadids> + <cputune> + <vcpupin vcpu='0' cpuset='1'/> + <vcpupin vcpu='1' cpuset='2'/> + <vcpupin vcpu='2' cpuset='3'/> + <vcpupin vcpu='3' cpuset='4'/> + <vcpupin vcpu='4' cpuset='5'/> + <vcpupin vcpu='5' cpuset='6'/> + <vcpupin vcpu='6' cpuset='7'/> + <vcpupin vcpu='7' cpuset='9'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='11'/> + <vcpupin vcpu='10' cpuset='12'/> + <vcpupin vcpu='11' cpuset='13'/> + <vcpupin vcpu='12' cpuset='14'/> + <vcpupin vcpu='13' cpuset='15'/> + <vcpupin vcpu='14' cpuset='17'/> + <vcpupin vcpu='15' cpuset='18'/> + <vcpupin vcpu='16' cpuset='19'/> + <vcpupin vcpu='17' cpuset='20'/> + <vcpupin vcpu='18' cpuset='21'/> + <vcpupin vcpu='19' cpuset='22'/> + <vcpupin vcpu='20' cpuset='23'/> + <vcpupin vcpu='21' cpuset='25'/> + <vcpupin vcpu='22' cpuset='26'/> + <vcpupin vcpu='23' cpuset='27'/> + <vcpupin vcpu='24' cpuset='28'/> + <vcpupin vcpu='25' cpuset='29'/> + <vcpupin vcpu='26' cpuset='30'/> + <vcpupin vcpu='27' cpuset='31'/> + <emulatorpin cpuset='0,8,16,24'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-q35-8.2'>hvm</type> + <loader readonly='yes' type='pflash'>/opt/macos/AUDK_CODE.fd</loader> + <nvram>/opt/macos/AUDK_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='2' dies='1' clusters='1' cores='8' 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/bin/qemu-system-x86_64</emulator> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x8' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x9' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0xc' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='c8:2a:14:66:2c:a1'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='c8:2a:14:31:32:e2'/> + <source bridge='br1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='keyboard' bus='ps2'/> + <input type='mouse' bus='ps2'/> + <audio id='1' type='none'/> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </source> + <rom file='/opt/gpu-bios/6900xt.rom'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/> + </source> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x046d'/> + <product id='0x0892'/> + </source> + <address type='usb' bus='0' port='2'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x148f'/> + <product id='0x3070'/> + </source> + <address type='usb' bus='0' port='1'/> + </hostdev> + <watchdog model='itco' action='reset'/> + <memballoon model='none'/> + </devices> + <qemu:commandline> + <qemu:arg value='-smbios'/> + <qemu:arg value='type=2'/> + <qemu:arg value='-global'/> + <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-speed=8'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-width=16'/> + <qemu:arg value='-cpu'/> + <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/> + </qemu:commandline> +</domain> +``` + +06:00.0/1 --> gpu +00:1b.0 --> audio +0c:00.0 --> sata controller +84:00.0 --> usb controller +0x046d 0x0892 --> usb webcam +0x148f 0x3070 --> usb wifi diff --git a/results/classifier/105/KVM/2363 b/results/classifier/105/KVM/2363 new file mode 100644 index 00000000..17a5bd86 --- /dev/null +++ b/results/classifier/105/KVM/2363 @@ -0,0 +1,14 @@ +KVM: 0.912 +device: 0.835 +instruction: 0.583 +network: 0.523 +graphic: 0.412 +mistranslation: 0.412 +semantic: 0.360 +boot: 0.312 +assembly: 0.302 +other: 0.277 +socket: 0.231 +vnc: 0.174 + +How can I enable MBI support in QEMU when running in KVM mode? diff --git a/results/classifier/105/KVM/239 b/results/classifier/105/KVM/239 new file mode 100644 index 00000000..e4dd81b5 --- /dev/null +++ b/results/classifier/105/KVM/239 @@ -0,0 +1,14 @@ +KVM: 0.991 +mistranslation: 0.988 +device: 0.831 +graphic: 0.750 +other: 0.714 +semantic: 0.698 +instruction: 0.554 +boot: 0.476 +vnc: 0.138 +assembly: 0.050 +socket: 0.022 +network: 0.011 + +Confusing error message when KVM can not start requested ARM CPU diff --git a/results/classifier/105/KVM/2392 b/results/classifier/105/KVM/2392 new file mode 100644 index 00000000..ba44f17d --- /dev/null +++ b/results/classifier/105/KVM/2392 @@ -0,0 +1,14 @@ +KVM: 0.961 +device: 0.804 +semantic: 0.491 +boot: 0.378 +mistranslation: 0.333 +network: 0.225 +instruction: 0.219 +graphic: 0.200 +other: 0.169 +vnc: 0.064 +assembly: 0.046 +socket: 0.032 + +Ability to use KVM on Windows diff --git a/results/classifier/105/KVM/2394 b/results/classifier/105/KVM/2394 new file mode 100644 index 00000000..5cf7e84a --- /dev/null +++ b/results/classifier/105/KVM/2394 @@ -0,0 +1,42 @@ +KVM: 0.995 +graphic: 0.991 +device: 0.952 +instruction: 0.936 +semantic: 0.907 +network: 0.861 +socket: 0.769 +other: 0.760 +mistranslation: 0.694 +boot: 0.693 +vnc: 0.624 +assembly: 0.423 + +kvm-unit-tests vmx failed +Description of problem: +On the Sierra Forest platform, the vmx test in kvm-unit-tests failed. But this issue cannot be replicated on Emerald Rapids platform. + +The first bad commit is ba6780905943696d790cc880c8e5684b51f027fe. +Steps to reproduce: +1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git + +2.cd kvm-unit-tests; ./configure + +3.make standalone + +4.rmmod kvm_intel + +5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y + +6.cd tests; ./vmx +Additional information: +... +FAIL: HOST_CR3 2000000001007000: vmlaunch fails + +FAIL: HOST_CR3 4000000001007000: vmlaunch fails +... + +SUMMARY: 430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped + +FAIL vmx (430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped) + +[error.log](/uploads/02456b40f2736c0bf34d3f4b3a0c872a/error.log) diff --git a/results/classifier/105/KVM/2398 b/results/classifier/105/KVM/2398 new file mode 100644 index 00000000..ad4fd8cf --- /dev/null +++ b/results/classifier/105/KVM/2398 @@ -0,0 +1,75 @@ +KVM: 0.683 +vnc: 0.627 +other: 0.568 +mistranslation: 0.540 +graphic: 0.509 +instruction: 0.502 +device: 0.487 +semantic: 0.458 +boot: 0.456 +socket: 0.454 +assembly: 0.454 +network: 0.402 + +qemu stalls when taking LUKS encrypted snapshot +Description of problem: +We have been dealing with an issue recently, where qemu occasionally stalls when taking LUKS encrypted snapshots. We were able to take several core dumps (one example below) when the issue was happening and, upon analyzing those, we found out that the issue is that the function [qcrypto_pbkdf2_count_iters](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L88) reaches an iteration number high enough that the algorithm takes a long time to finish. + +Upon investigation, we were able to see that this is happening because [start_ms and end_ms](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L115) have the same value, giving a delta of zero, causing the number of iterations to always increase. + +Here are the important parts of the coredump: + +``` +(gdb) bt +#0 0x00007fb00aba5489 in _gcry_sha256_transform_amd64_avx2 () at ../../cipher/sha256-avx2-bmi2-amd64.S:346 +#1 0x00007fb00aba3000 in sha256_final (context=0x55ab875d5028) at ../../cipher/sha256.c:591 +#2 0x00007fb00ab19dea in md_final (a=0x55ab82e1bf50) at ../../cipher/md.c:800 +#3 0x00007fb00ab19f89 in md_final (a=a@entry=0x55ab82e1bf50) at ../../cipher/md.c:1003 +#4 _gcry_md_ctl (hd=hd@entry=0x55ab82e1bf50, buflen=0, buffer=0x0, cmd=5) at ../../cipher/md.c:1012 +#5 0x00007fb00ab1a4d0 in _gcry_md_ctl (buflen=0, buffer=0x0, cmd=5, hd=0x55ab82e1bf50) at ../../cipher/md.c:1106 +#6 _gcry_md_read (hd=0x55ab82e1bf50, algo=algo@entry=0) at ../../cipher/md.c:1110 +#7 0x00007fb00ab1d9ef in _gcry_kdf_pkdf2 (passphrase=passphrase@entry=0x55ab8177f040, passphraselen=passphraselen@entry=64, hashalgo=hashalgo@entry=8, salt=salt@entry=0x55ab8397a1d4, saltlen=saltlen@entry=32, + iterations=iterations@entry=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../cipher/kdf.c:213 +#8 0x00007fb00ab1de3c in _gcry_kdf_pkdf2 (keybuffer=0x55ab817693c0, keysize=20, iterations=32768000000, saltlen=32, salt=0x55ab8397a1d4, hashalgo=8, passphraselen=64, passphrase=0x55ab8177f040) at ../../cipher/kdf.c:144 +#9 _gcry_kdf_derive (passphrase=0x55ab8177f040, passphraselen=64, algo=34, subalgo=8, salt=0x55ab8397a1d4, saltlen=32, iterations=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../cipher/kdf.c:286 +#10 0x00007fb00ab02299 in gcry_kdf_derive (passphrase=passphrase@entry=0x55ab8177f040, passphraselen=passphraselen@entry=64, algo=algo@entry=34, hashalgo=hashalgo@entry=8, salt=salt@entry=0x55ab8397a1d4, saltlen=saltlen@entry=32, + iterations=32768000000, keysize=20, keybuffer=0x55ab817693c0) at ../../src/visibility.c:1337 +#11 0x000055ab7f80ff83 in qcrypto_pbkdf2 (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=nkey@entry=64, + salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, iterations=iterations@entry=32768000000, + out=0x55ab817693c0 "C[\210\003\332\017b\350\f\257\377UP\257\262\275\033\v\034(", nout=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf-gcrypt.c:75 +#12 0x000055ab7f80fe66 in qcrypto_pbkdf2_count_iters (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=64, + salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, nout=nout@entry=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf.c:80 +#13 0x000055ab7f812930 in qcrypto_block_luks_create (block=0x55ab82944540, options=<optimized out>, optprefix=<optimized out>, initfunc=0x55ab7f7abad0 <qcow2_crypto_hdr_init_func>, writefunc=0x55ab7f7ac040 <qcow2_crypto_hdr_write_func>, + opaque=0x55ab83a32290, errp=0x55ab823873d0) at ./crypto/block-luks.c:1362 +#14 0x000055ab7f810d80 in qcrypto_block_create (options=options@entry=0x55ab818e1f40, optprefix=optprefix@entry=0x55ab7f99912b "encrypt.", initfunc=initfunc@entry=0x55ab7f7abad0 <qcow2_crypto_hdr_init_func>, + writefunc=writefunc@entry=0x55ab7f7ac040 <qcow2_crypto_hdr_write_func>, opaque=opaque@entry=0x55ab83a32290, errp=errp@entry=0x55ab823873d0) at ./crypto/block.c:106 +#15 0x000055ab7f7b0f79 in qcow2_set_up_encryption (errp=0x55ab823873d0, cryptoopts=0x55ab818e1f40, bs=0x55ab83a32290) at ./block/qcow2.c:2996 +#16 qcow2_co_create (create_options=<optimized out>, errp=0x55ab823873d0) at ./block/qcow2.c:3529 +#17 0x000055ab7f7e2fca in blockdev_create_run (job=0x55ab82387350, errp=0x55ab823873d0) at ./block/create.c:46 +#18 0x000055ab7f79cf6f in job_co_entry (opaque=0x55ab82387350) at ./job.c:878 +#19 0x000055ab7f87e09c in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ./util/coroutine-ucontext.c:115 +#20 0x00007fb009a14680 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#21 0x00007ffd40716530 in ?? () +#22 0x0000000000000000 in ?? () +(gdb) frame 12 +#12 0x000055ab7f80fe66 in qcrypto_pbkdf2_count_iters (hash=hash@entry=QCRYPTO_HASH_ALG_SHA256, key=key@entry=0x55ab8177f040 "\b@\327\061\177F\f\345\200Bw#", nkey=64, + salt=salt@entry=0x55ab8397a1d4 "\"ͧ\322+\201!\375\177\020\037\252Hg$\271\021\340\343T\021OKָ\234m\304\066g\024\276", nsalt=nsalt@entry=32, nout=nout@entry=20, errp=0x7fa7565e5df8) at ./crypto/pbkdf.c:80 +80 if (qcrypto_pbkdf2(hash, +(gdb) info locals +ret = 18446744073709551615 +out = 0x55ab817693c0 "C[\210\003\332\017b\350\f\257\377UP\257\262\275\033\v\034(" +iterations = 32768000000 +delta_ms = <optimized out> +start_ms = 35357141 +end_ms = 35357141 +``` + +We did some investigation on the getrusage system call, which is [used to calculate start_ms and end_ms](https://github.com/qemu/qemu/blob/master/crypto/pbkdf.c#L72) and found some patches which indicate that it might not be that accurate: + +https://github.com/torvalds/linux/commit/3dc167ba5729ddd2d8e3fa1841653792c295d3f1 + +https://lore.kernel.org/lkml/20221226031010.4079885-1-maxing.lan@bytedance.com/t/#m1c7f2fdc0ea742776a70fd1aa2a2e414c437f534 + +So far we have only seen this with Windows guests, but it might be a red herring. It happens maybe once a month and we were unable to get a reproducer. + +I'm open to proposing a fix for this, but how could we measure this without relying on getrusage which is causing us trouble? Any other suggestions or tips on this? diff --git a/results/classifier/105/KVM/2412 b/results/classifier/105/KVM/2412 new file mode 100644 index 00000000..7b092660 --- /dev/null +++ b/results/classifier/105/KVM/2412 @@ -0,0 +1,113 @@ +KVM: 0.862 +other: 0.846 +device: 0.836 +instruction: 0.823 +semantic: 0.818 +mistranslation: 0.792 +vnc: 0.789 +graphic: 0.775 +assembly: 0.771 +boot: 0.751 +network: 0.731 +socket: 0.716 + +Race condition in megasas device +Description of problem: +Race condition DoS in megasas device was found during **fuzzing**. I'm not sure about **worst case impact**, but for now I can make a suggestion: worst case might be leading to **DoS**, but probably it's a rabbit hole. So if we dig deeper we might find something like CWE-200 or CWE-202 (Exposure of Sensitive Information to an Unauthorized Actor and so on). Also, I think that we should analyse thread usage in this case and make all operations thread-safe, but it's not my business of course. As a consequence, I do not suggest any patch (at least for now). +Steps to reproduce: +This command: + +`cat << EOF | ./build/qemu-system-x86_64 \`\ +`-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \`\ +`-device megasas -device scsi-cd,drive=null0 -blockdev \`\ +`driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio`\ +`outl 0xcf8 0x80000818`\ +`outl 0xcfc 0xc000`\ +`outl 0xcf8 0x80000804`\ +`outw 0xcfc 0x05`\ +`write 0x20 0x1 0x03`\ +`write 0x26 0x1 0x08`\ +`write 0x27 0x1 0x01`\ +`write 0x30 0x1 0x02`\ +`write 0x40 0x1 0x08`\ +`write 0x57 0x1 0x01`\ +`write 0x5a 0x1 0x08`\ +`outl 0xc03d 0x20000000`\ +`outl 0xc03d 0x00`\ +`EOF`\ +\ +Results in:\ +\ +`[R +0.081916] outl 0xcf8 0x80000818`\ +`[S +0.081986] OK`\ +`OK`\ +`[R +0.082033] outl 0xcfc 0xc000`\ +`[S +0.082083] OK`\ +`OK`\ +`[R +0.082102] outl 0xcf8 0x80000804`\ +`[S +0.082117] OK`\ +`OK`\ +`[R +0.082133] outw 0xcfc 0x05`\ +`[S +0.082926] OK`\ +`OK`\ +`[R +0.082961] write 0x20 0x1 0x03`\ +`[S +0.083688] OK`\ +`OK`\ +`[R +0.083731] write 0x26 0x1 0x08`\ +`[S +0.083754] OK`\ +`OK`\ +`[R +0.083780] write 0x27 0x1 0x01`\ +`[S +0.083799] OK`\ +`OK`\ +`[R +0.083817] write 0x30 0x1 0x02`\ +`[S +0.083850] OK`\ +`OK`\ +`[R +0.083872] write 0x40 0x1 0x08`\ +`[S +0.083903] OK`\ +`OK`\ +`[R +0.083925] write 0x57 0x1 0x01`\ +`[S +0.083947] OK`\ +`OK`\ +`[R +0.083962] write 0x5a 0x1 0x08`\ +`[S +0.083985] OK`\ +`OK`\ +`[R +0.084000] outl 0xc03d 0x20000000`\ +`[S +0.085531] OK`\ +`OK`\ +`[R +0.085570] outl 0xc03d 0x00`\ +`[S +0.085673] OK`\ +`OK`\ +`qemu/include/exec/memory.h:1152:12: runtime error: member access within null pointer of type 'AddressSpace' (aka 'struct AddressSpace')`\ +`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qemu/include/exec/memory.h:1152:12 in` \ +`AddressSanitizer:DEADLYSIGNAL`\ +`=================================================================`\ +`==168244==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x56259b9829ac bp 0x000000000001 sp 0x7ffe62140220 T0)`\ +`==168244==The signal is caused by a READ memory access.`\ +`==168244==Hint: address points to the zero page.`\ + `#0 0x56259b9829ac in address_space_to_flatview qemu/include/exec/memory.h:1152:12`\ + `#1 0x56259b9829ac in address_space_write qemu/build/../system/physmem.c:2929:14`\ + `#2 0x56259b98665e in address_space_unmap qemu/build/../system/physmem.c:3272:9`\ + `#3 0x56259af31dce in dma_memory_unmap qemu/include/sysemu/dma.h:236:5`\ + `#4 0x56259af31dce in dma_blk_unmap qemu/build/../system/dma-helpers.c:93:9`\ + `#5 0x56259af2f220 in dma_complete qemu/build/../system/dma-helpers.c:105:5`\ + `#6 0x56259af2f220 in dma_blk_cb qemu/build/../system/dma-helpers.c:129:9`\ + `#7 0x56259bce7041 in blk_aio_complete qemu/build/../block/block-backend.c:1555:9`\ + `#8 0x56259c224495 in aio_bh_call qemu/build/../util/async.c:171:5`\ + `#9 0x56259c224ca6 in aio_bh_poll qemu/build/../util/async.c:218:13`\ + `#10 0x56259c1b9b89 in aio_dispatch qemu/build/../util/aio-posix.c:423:5`\ + `#11 0x56259c228f40 in aio_ctx_dispatch qemu/build/../util/async.c:360:5`\ + `#12 0x7f2b8c0a07a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)`\ + `#13 0x56259c22a1ed in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9`\ + `#14 0x56259c22a1ed in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5`\ + `#15 0x56259c22a1ed in main_loop_wait qemu/build/../util/main-loop.c:589:11`\ + `#16 0x56259af5159e in qemu_main_loop qemu/build/../system/runstate.c:796:9`\ + `#17 0x56259baefdb4 in qemu_default_main qemu/build/../system/main.c:37:14`\ + `#18 0x7f2b8aff7249 (/lib/x86_64-linux-gnu/libc.so.6+0x27249) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\ + `#19 0x7f2b8aff7304 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27304) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\ + `#20 0x562599f60b70 in _start (qemu/build/qemu-system-x86_64+0x20feb70) (BuildId: 48f1333e9a9d60383d8c9e0db5f690e7c26e1bb2)`\ +`AddressSanitizer can not provide additional info.`\ +`SUMMARY: AddressSanitizer: SEGV qemu/include/exec/memory.h:1152:12 in address_space_to_flatview`\ +`==168244==ABORTING` + +\ +But, if we manually put all of those qtest commands and wait for each command to complete, QEMU doesn't fail. It's because of possible race condition - while QEMU still mapping memory, we already starting to unmap it. It results in this crash. diff --git a/results/classifier/105/KVM/2436 b/results/classifier/105/KVM/2436 new file mode 100644 index 00000000..371c3114 --- /dev/null +++ b/results/classifier/105/KVM/2436 @@ -0,0 +1,14 @@ +KVM: 0.968 +device: 0.947 +instruction: 0.918 +network: 0.914 +mistranslation: 0.504 +semantic: 0.350 +graphic: 0.302 +vnc: 0.184 +boot: 0.176 +assembly: 0.138 +other: 0.079 +socket: 0.011 + +virtio kvm iofd sigfault bypass diff --git a/results/classifier/105/KVM/2445 b/results/classifier/105/KVM/2445 new file mode 100644 index 00000000..a48fed90 --- /dev/null +++ b/results/classifier/105/KVM/2445 @@ -0,0 +1,100 @@ +KVM: 0.617 +graphic: 0.548 +vnc: 0.523 +other: 0.495 +instruction: 0.482 +assembly: 0.454 +device: 0.448 +mistranslation: 0.437 +semantic: 0.431 +boot: 0.403 +network: 0.386 +socket: 0.368 + +virtio-pci: the number of irq routes keeps increasing and qemu abort +Description of problem: + +Steps to reproduce: +1. Start a virtual machine and add a virtio-scsi controller for vm, E.g: + + `<controller type='scsi' model='virtio-scsi' index='1'/>` +2. write rand value and rand address in port IO address space of virtio-scsi device in the guest, E.g: + + ``` + int main(){ + iopl(3); + srand(10001); + unsigned port_base = 0xc000; + unsigned port_space_size = 32; + time_t now; + struct tm *tm_struct; + int i; + + for (i=0;i<100000000;i++){ + outb(rand()&0xff,port_base+rand()%port_space_size); + outw(rand()&0xffff,port_base+rand()%port_space_size); + outl(rand(),port_base+rand()%port_space_size); + } + return 0; + } + ``` + + or write some special value: + + ``` + int main(){ + iopl(3); + srand(10001); + unsigned port_base = 0xc000; + unsigned port_space_size = 32; + int i; + + for (i=0;i<100000000;i++){ + outw(13170, port_base + 18); // DRIVER + outw(16, port_base + 20); // config_vector = 16 + outw(34244, port_base + 18); // DRIVE OK + outw(29, port_base + 20); // config_vector = 65535 + outw(5817, port_base + 18); // not DRIVE OK + usleep(1000); + } + return 0; + } + ``` +3. the number of irq routes will keep increasing and qemu process on the host will abort +Additional information: +stack infomation after qemu process aborts: + +``` +#0 0x00007f3cd38500ff in () at /usr/lib64/libc.so.6 +#1 0x00007f3cd3803d06 in raise () at /usr/lib64/libc.so.6 +#2 0x00007f3cd37ef1f7 in abort () at /usr/lib64/libc.so.6 +#3 0x0000563055c54d68 in kvm_irqchip_commit_routes (s=0x563058b24bc0) at ../accel/kvm/kvm-all.c:1872 +#4 kvm_irqchip_commit_routes (s=0x563058b24bc0) at ../accel/kvm/kvm-all.c:1855 +#5 0x0000563055a1c242 in kvm_irqchip_commit_route_changes (c=0x7f3ccaffc040) at /Images/syg/code/openEuler/qemu/include/sysemu/kvm.h:470 +#6 kvm_virtio_pci_vq_vector_use (vector=18, proxy=0x563059b7f320) at ../hw/virtio/virtio-pci.c:875 +#7 kvm_virtio_pci_vector_use_one (proxy=proxy@entry=0x563059b7f320, queue_no=queue_no@entry=17) at ../hw/virtio/virtio-pci.c:948 +#8 0x0000563055a1d718 in kvm_virtio_pci_vector_vq_use (nvqs=18, proxy=0x563059b7f320) at ../hw/virtio/virtio-pci.c:1010 +#9 virtio_pci_set_guest_notifiers (d=0x563059b7f320, nvqs=18, assign=<optimized out>) at ../hw/virtio/virtio-pci.c:1373 +#10 0x00005630559cb5f9 in virtio_scsi_dataplane_start (vdev=0x563059b876f0) at ../hw/scsi/virtio-scsi-dataplane.c:116 +#11 0x0000563055a194f2 in virtio_bus_start_ioeventfd (bus=bus@entry=0x563059b87670) at ../hw/virtio/virtio-bus.c:236 +#12 0x0000563055a1c9f2 in virtio_pci_start_ioeventfd (proxy=0x563059b7f320) at ../hw/virtio/virtio-pci.c:375 +#13 virtio_ioport_write (val=34244, addr=18, opaque=0x563059b7f320) at ../hw/virtio/virtio-pci.c:471 +#14 virtio_pci_config_write (opaque=0x563059b7f320, addr=18, val=<optimized out>, size=<optimized out>) at ../hw/virtio/virtio-pci.c:617 +#15 0x0000563055bfb3af in memory_region_write_accessor (mr=mr@entry=0x563059b7fd50, addr=18, value=value@entry=0x7f3ccaffc2c8, size=size@entry=2, shift=<optimized out>, mask=mask@entry=65535, attrs=...) + at ../system/memory.c:497 +#16 0x0000563055bfc05e in access_with_adjusted_size (addr=addr@entry=18, value=value@entry=0x7f3ccaffc2c8, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn= + 0x563055bfb330 <memory_region_write_accessor>, mr=0x563059b7fd50, attrs=...) at ../system/memory.c:573 +#17 0x0000563055bfd074 in memory_region_dispatch_write (mr=0x563059b7fd50, addr=18, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528 +#18 0x0000563055c040f4 in flatview_write_continue + (fv=fv@entry=0x7f3aa40198b0, addr=addr@entry=49170, attrs=attrs@entry=..., ptr=ptr@entry=0x7f3cd0002000, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=<optimized out>) + at /Images/syg/code/openEuler/qemu/include/qemu/host-utils.h:238 +#19 0x0000563055c043e0 in flatview_write (fv=0x7f3aa40198b0, addr=addr@entry=49170, attrs=attrs@entry=..., buf=buf@entry=0x7f3cd0002000, len=len@entry=2) at ../system/physmem.c:2799 +#20 0x0000563055c07c48 in address_space_write (len=2, buf=0x7f3cd0002000, attrs=..., addr=49170, as=0x563056cc8fe0 <address_space_io>) at ../system/physmem.c:2906 +#21 address_space_rw (as=0x563056cc8fe0 <address_space_io>, addr=addr@entry=49170, attrs=attrs@entry=..., buf=0x7f3cd0002000, len=len@entry=2, is_write=is_write@entry=true) at ../system/physmem.c:2916 +#22 0x0000563055c58663 in kvm_handle_io (count=1, size=2, direction=<optimized out>, data=<optimized out>, attrs=..., port=49170) at ../accel/kvm/kvm-all.c:2670 +#23 kvm_cpu_exec (cpu=cpu@entry=0x563058ee2a40) at ../accel/kvm/kvm-all.c:2943 +#24 0x0000563055c59965 in kvm_vcpu_thread_fn (arg=0x563058ee2a40) at ../accel/kvm/kvm-accel-ops.c:51 +#25 0x0000563055ddb9df in qemu_thread_start (args=0x563058eecaa0) at ../util/qemu-thread-posix.c:541 +#26 0x00007f3cd384e51a in () at /usr/lib64/libc.so.6 +#27 0x00007f3cd38d0e00 in () at /usr/lib64/libc.so.6 +``` diff --git a/results/classifier/105/KVM/2447 b/results/classifier/105/KVM/2447 new file mode 100644 index 00000000..7351e4dd --- /dev/null +++ b/results/classifier/105/KVM/2447 @@ -0,0 +1,36 @@ +KVM: 0.506 +device: 0.445 +graphic: 0.410 +semantic: 0.341 +socket: 0.235 +mistranslation: 0.204 +vnc: 0.152 +boot: 0.135 +network: 0.121 +other: 0.118 +instruction: 0.116 +assembly: 0.058 + +With -display sdl,gl=on and 3D acceleration, the position of mouse does not show correctly +Description of problem: +Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px). + +Split off from https://gitlab.com/qemu-project/qemu/-/issues/761 + +VM window is not necessary to be resized to reproduce this bug. If your VM desktop comes 1920x1080 originally, the bug can be reproduced from the very start. + +Smaller resolutions show this bug too, but it not so noticeable. +Steps to reproduce: +1. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe +2. Go to https://www.kali.org/get-kali/#kali-virtual-machines and click big QEMU 64 icon, and wait till kali-linux-2024.2-qemu-amd64.7z has been downloaded +3. Extract kali-linux-2024.2-qemu-amd64.qcow2 from kali-linux-2024.2-qemu-amd64.7z +4. Run it: `qemu-system-x86_64.exe -accel tcg -device virtio-vga-gl -display sdl,gl=on -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` +5. Enter `kali` as user and `kali` as password when prompted +6. When the desktop is shown up, click the leftmost, upmost blue "Applications" button. Then click Settings -\> Display +7. Pick 1920x1080 as resolution and click Apply, then Keep this configuration. +8. Click Firefox Browser icon on the top panel. +9. When the browser starts working, experience how hard to use its interface, though it's fast. Real mouse position is nearly 100 px on the left of drawn cursor. The closer the cursor to the lower right corner of the VM window, the worse (divergence becomes way bigger than 100 px). +Additional information: +Run `qemu-system-x86_64.exe -accel tcg -device virtio-vga -display sdl -hda C:\kali-linux-2024.2-qemu-amd64.qcow2 -usb -device usb-tablet -m 4096 -machine q35 -smp 2 -cpu Westmere` and experience correct behavior. + +Mouse in Gtk mode works ok. OpenGL not available for Windows in GTK mode. diff --git a/results/classifier/105/KVM/252 b/results/classifier/105/KVM/252 new file mode 100644 index 00000000..9ee1ca2c --- /dev/null +++ b/results/classifier/105/KVM/252 @@ -0,0 +1,14 @@ +KVM: 0.975 +device: 0.883 +graphic: 0.526 +instruction: 0.492 +semantic: 0.449 +other: 0.379 +network: 0.346 +mistranslation: 0.289 +vnc: 0.191 +boot: 0.068 +assembly: 0.029 +socket: 0.023 + +KVM Old ATI(pre) AMD card passthrough is not working diff --git a/results/classifier/105/KVM/2548 b/results/classifier/105/KVM/2548 new file mode 100644 index 00000000..cec4482b --- /dev/null +++ b/results/classifier/105/KVM/2548 @@ -0,0 +1,419 @@ +mistranslation: 0.962 +KVM: 0.943 +graphic: 0.938 +other: 0.933 +vnc: 0.927 +semantic: 0.924 +assembly: 0.918 +network: 0.916 +device: 0.914 +instruction: 0.914 +socket: 0.912 +boot: 0.904 + +Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed. +Description of problem: +Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed. + +The TD PID needs to be either `USB_TOKEN_IN` or `USB_TOKEN_OUT` in `usb_ep_get`, but in the caller `uhci_handle_td` it may be `USB_TOKEN_SETUP`. + +An unprivileged guest user may be able to reach the assertion, I think this bug is quite akin to CVE-2024-3567 (https://gitlab.com/qemu-project/qemu/-/issues/2273) : + +Users are not directly able to craft URBs, however as a user, one might be able to find a kernel path that would send a TD with PID `USB_TOKEN_SETUP` to QEMU (which is called `USB_PID_SETUP` in Linux). +For instance in the Linux Kernel, `uhci_submit_control` in `drivers/usb/host/uhci-q.c:789` does link a `USB_PID_SETUP` TD to the URB. +Steps to reproduce: +Minimized reproducer: + +``` +cat << EOF | ./qemu/build2/qemu-system-x86_64 -machine q35 -nodefaults \ +-device \ +ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \ +-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,multifunction=on,masterbus=i\ +ch9-ehci-1.0,firstport=0 -device ich9-usb-uhci2,bus=pcie.0,addr=1d.1,mul\ +tifunction=on,masterbus=ich9-ehci-1.0,firstport=2 -device ich9-usb-uhci3\ +,bus=pcie.0,addr=1d.2,multifunction=on,masterbus=ich9-ehci-1.0,firstport\ +=4 -drive if=none,id=usbcdrom,media=cdrom -device \ +usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 -device \ +usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom -qtest stdio +outl 0xcf8 0x8000e900 +inw 0xcfc +outl 0xcf8 0x8000e920 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000e920 +inl 0xcfc +outl 0xcf8 0x8000e920 +outl 0xcfc 0xc001 +outl 0xcf8 0x8000e904 +inw 0xcfc +outl 0xcf8 0x8000e904 +outw 0xcfc 0x7 +outl 0xcf8 0x8000e904 +inw 0xcfc +outl 0xcf8 0x8000ef00 +inw 0xcfc +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000ef10 +inl 0xcfc +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000ef04 +inw 0xcfc +outl 0xcf8 0x8000ef04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000ef04 +inw 0xcfc +outl 0xcf8 0x8000ea00 +inw 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000ea20 +inl 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0xc021 +outl 0xcf8 0x8000ea04 +inw 0xcfc +outl 0xcf8 0x8000ea04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000ea04 +inw 0xcfc +outl 0xcf8 0x8000e800 +inw 0xcfc +outl 0xcf8 0x8000e820 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000e820 +inl 0xcfc +outl 0xcf8 0x8000e820 +outl 0xcfc 0xc041 +outl 0xcf8 0x8000e804 +inw 0xcfc +outl 0xcf8 0x8000e804 +outw 0xcfc 0x7 +outl 0xcf8 0x8000e804 +inw 0xcfc +outl 0xcf8 0x8000fa00 +inw 0xcfc +outl 0xcf8 0x8000fa20 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000fa20 +inl 0xcfc +outl 0xcf8 0x8000fa20 +outl 0xcfc 0xc061 +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000fa24 +inl 0xcfc +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x8000fa04 +inw 0xcfc +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa04 +inw 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0x625f69a0 +outb 0xc040 0x46 +outb 0xc040 0x69 +inb 0xc000 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +clock_step +write 0x0 0x4 0x64657669 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +write 0xff000000 0x8 0x000000ff6c6f6766 +write 0xff000008 0x8 0x8d6c65652d736400 +outb 0xc040 0x69 +outl 0xcf8 0x8000ef76 +outw 0xcfc 0x6563 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +inb 0xc000 +clock_step +write 0x4 0x4 0x64657669 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +write 0xff000000 0x8 0x000000ff6c6f6766 +write 0xff000008 0x8 0x8d6c65652d736400 +outb 0xc040 0x69 +outw 0xc003 0x6769 +outb 0xc040 0x69 +readq 0xe0000074 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +clock_step +write 0x8 0x4 0x00000100 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +write 0xff000000 0x8 0x6465766963656d69 +write 0xff000008 0x8 0x740d00699b652d63 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +clock_step +write 0xc 0x4 0x000000ff +write 0xff000000 0x8 0x0000010000000069 +write 0xff000008 0x8 0x636c395f61707269 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +outw 0xc003 0x6f00 +outb 0xc040 0x69 +outl 0xc053 0x6378616d +clock_step +write 0x10 0x4 0x000000ff +write 0xff000000 0x8 0x6465766963656d69 +write 0xff000008 0x8 0x740d00699b652d63 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +outb 0xc051 0x6d +outb 0xc04f 0x61 +outb 0xc040 0x69 +clock_step +write 0x14 0x4 0x000000ff +write 0xff000000 0x8 0x0000010000000069 +write 0xff000008 0x8 0x636c395f61707269 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +EOF +``` + +# Additional information +The crash report triggered by the reproducer is: + +``` +[R +0.033173] outl 0xcf8 0x8000e900 +[S +0.033189] [R +0.033195] inw 0xcfc +[S +0.033205] [R +0.033212] outl 0xcf8 0x8000e920 +[S +0.033218] [R +0.033222] outl 0xcfc 0xffffffff +[S +0.033231] [R +0.033235] outl 0xcf8 0x8000e920 +[S +0.033241] [R +0.033245] inl 0xcfc +[S +0.033250] [R +0.033255] outl 0xcf8 0x8000e920 +[S +0.033261] [R +0.033265] outl 0xcfc 0xc001 +[S +0.033271] [R +0.033275] outl 0xcf8 0x8000e904 +[S +0.033281] [R +0.033285] inw 0xcfc +[S +0.033290] [R +0.033295] outl 0xcf8 0x8000e904 +[S +0.033300] [R +0.033306] outw 0xcfc 0x7 +[S +0.033755] [R +0.033767] outl 0xcf8 0x8000e904 +[S +0.033774] [R +0.033779] inw 0xcfc +[S +0.033785] [R +0.033792] outl 0xcf8 0x8000ef00 +[S +0.033798] [R +0.033802] inw 0xcfc +[S +0.033808] [R +0.033813] outl 0xcf8 0x8000ef10 +[S +0.033818] [R +0.033840] outl 0xcfc 0xffffffff +[S +0.033848] [R +0.033853] outl 0xcf8 0x8000ef10 +[S +0.033859] [R +0.033864] inl 0xcfc +[S +0.033870] [R +0.033875] outl 0xcf8 0x8000ef10 +[S +0.033880] [R +0.033884] outl 0xcfc 0xe0000000 +[S +0.033891] [R +0.033895] outl 0xcf8 0x8000ef04 +[S +0.033901] [R +0.033904] inw 0xcfc +[S +0.033909] [R +0.033916] outl 0xcf8 0x8000ef04 +[S +0.033922] [R +0.033926] outw 0xcfc 0x7 +[S +0.034381] [R +0.034389] outl 0xcf8 0x8000ef04 +[S +0.034395] [R +0.034399] inw 0xcfc +[S +0.034405] [R +0.034412] outl 0xcf8 0x8000ea00 +[S +0.034417] [R +0.034421] inw 0xcfc +[S +0.034427] [R +0.034431] outl 0xcf8 0x8000ea20 +[S +0.034437] [R +0.034441] outl 0xcfc 0xffffffff +[S +0.034448] [R +0.034452] outl 0xcf8 0x8000ea20 +[S +0.034457] [R +0.034463] inl 0xcfc +[S +0.034469] [R +0.034474] outl 0xcf8 0x8000ea20 +[S +0.034480] [R +0.034484] outl 0xcfc 0xc021 +[S +0.034490] [R +0.034494] outl 0xcf8 0x8000ea04 +[S +0.034500] [R +0.034504] inw 0xcfc +[S +0.034509] [R +0.034515] outl 0xcf8 0x8000ea04 +[S +0.034521] [R +0.034525] outw 0xcfc 0x7 +[S +0.034948] [R +0.034955] outl 0xcf8 0x8000ea04 +[S +0.034961] [R +0.034965] inw 0xcfc +[S +0.034971] [R +0.034989] outl 0xcf8 0x8000e800 +[S +0.034996] [R +0.035000] inw 0xcfc +[S +0.035005] [R +0.035010] outl 0xcf8 0x8000e820 +[S +0.035016] [R +0.035020] outl 0xcfc 0xffffffff +[S +0.035027] [R +0.035033] outl 0xcf8 0x8000e820 +[S +0.035039] [R +0.035043] inl 0xcfc +[S +0.035048] [R +0.035053] outl 0xcf8 0x8000e820 +[S +0.035059] [R +0.035065] outl 0xcfc 0xc041 +[S +0.035071] [R +0.035075] outl 0xcf8 0x8000e804 +[S +0.035081] [R +0.035084] inw 0xcfc +[S +0.035089] [R +0.035094] outl 0xcf8 0x8000e804 +[S +0.035100] [R +0.035103] outw 0xcfc 0x7 +[S +0.035525] [R +0.035532] outl 0xcf8 0x8000e804 +[S +0.035538] [R +0.035542] inw 0xcfc +[S +0.035548] [R +0.035553] outl 0xcf8 0x8000fa00 +[S +0.035558] [R +0.035562] inw 0xcfc +[S +0.035567] [R +0.035572] outl 0xcf8 0x8000fa20 +[S +0.035578] [R +0.035581] outl 0xcfc 0xffffffff +[S +0.035589] [R +0.035594] outl 0xcf8 0x8000fa20 +[S +0.035600] [R +0.035604] inl 0xcfc +[S +0.035609] [R +0.035613] outl 0xcf8 0x8000fa20 +[S +0.035618] [R +0.035623] outl 0xcfc 0xc061 +[S +0.035629] [R +0.035633] outl 0xcf8 0x8000fa24 +[S +0.035638] [R +0.035642] outl 0xcfc 0xffffffff +[S +0.035648] [R +0.035652] outl 0xcf8 0x8000fa24 +[S +0.035658] [R +0.035664] inl 0xcfc +[S +0.035669] [R +0.035673] outl 0xcf8 0x8000fa24 +[S +0.035679] [R +0.035683] outl 0xcfc 0xe0001000 +[S +0.035689] [R +0.035696] outl 0xcf8 0x8000fa04 +[S +0.035702] [R +0.035706] inw 0xcfc +[S +0.035711] [R +0.035716] outl 0xcf8 0x8000fa04 +[S +0.035722] [R +0.035725] outw 0xcfc 0x7 +[S +0.036402] [R +0.036412] outl 0xcf8 0x8000fa04 +[S +0.036418] [R +0.036422] inw 0xcfc +[S +0.036434] [R +0.036442] outl 0xcf8 0x8000ea20 +[S +0.036448] [R +0.036463] outl 0xcfc 0x625f69a0 +[S +0.036906] [I +0.036981] CLOSED +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] inb 0xc000 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x0 0x4 0x64657669 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x8000ef76 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xcfc 0x6563 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] inb 0xc000 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x4 0x4 0x64657669 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc003 0x6769 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] readq 0xe0000074 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x8 0x4 0x00000100 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x6465766963656d69 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xc 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x0000010000000069 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x636c395f61707269 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc003 0x6f00 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xc053 0x6378616d +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x6465766963656d69 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc051 0x6d +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc04f 0x61 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x14 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x0000010000000069 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x636c395f61707269 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +qemu-fuzz-x86_64: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +==892641== ERROR: libFuzzer: deadly signal + #0 0x557dd985fc41 in __sanitizer_print_stack_trace (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x20b2c41) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #1 0x557dd97cfa58 in fuzzer::PrintStackTrace() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2022a58) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #2 0x557dd97b5ae3 in fuzzer::Fuzzer::CrashCallback() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2008ae3) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #3 0x7fd7e623c45f (/lib/x86_64-linux-gnu/libc.so.6+0x3c45f) (BuildId: d320ce4e63925d698610ed423fc4b1f0e8ed51f1) + #4 0x7fd7e629152a in __pthread_kill_implementation nptl/pthread_kill.c:43:17 + #5 0x7fd7e629152a in __pthread_kill_internal nptl/pthread_kill.c:78:10 + #6 0x7fd7e629152a in pthread_kill nptl/pthread_kill.c:89:10 + #7 0x7fd7e623c3b5 in raise signal/../sysdeps/posix/raise.c:26:13 + #8 0x7fd7e622287b in abort stdlib/abort.c:79:7 + #9 0x7fd7e622279a in __assert_fail_base assert/assert.c:92:3 + #10 0x7fd7e6233b65 in __assert_fail assert/assert.c:101:3 + #11 0x557dda3b67c6 in usb_ep_get /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/core.c:744:5 + #12 0x557dda3d8820 in uhci_handle_td /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:819:14 + #13 0x557dda3d41ed in uhci_process_frame /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1022:15 + #14 0x557dda3cbf7e in uhci_frame_timer /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1121:9 + #15 0x557ddb90c0ff in timerlist_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:576:9 + #16 0x557ddb90d3e8 in qemu_clock_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:590:12 + #17 0x557ddb90d3e8 in qemu_clock_advance_virtual_time /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:696:9 + #18 0x557dda67fa2f in qtest_process_command /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:722:9 + #19 0x557dda67b3bb in qtest_process_inbuf /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:776:9 + #20 0x557dda67acf6 in qtest_server_inproc_recv /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:907:9 + #21 0x557ddb5fa3e2 in qtest_sendf /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:640:5 + #22 0x557ddb5fa4f4 in qtest_clock_step_next /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:1009:5 + #23 0x557ddb67c2ef in generic_fuzz /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/generic_fuzz.c:667:13 + #24 0x557ddb66e807 in LLVMFuzzerTestOneInput /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/fuzz.c:158:5 + #25 0x557dd97b6f52 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2009f52) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #26 0x557dd97a1080 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff4080) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #27 0x557dd97a6d07 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff9d07) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #28 0x557dd97d0292 in main (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2023292) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #29 0x7fd7e6223a8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #30 0x7fd7e6223b48 in __libc_start_main csu/../csu/libc-start.c:360:3 + #31 0x557dd979b884 in _start (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1fee884) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) +``` diff --git a/results/classifier/105/KVM/2566 b/results/classifier/105/KVM/2566 new file mode 100644 index 00000000..14a74b73 --- /dev/null +++ b/results/classifier/105/KVM/2566 @@ -0,0 +1,132 @@ +KVM: 0.576 +network: 0.557 +device: 0.472 +instruction: 0.467 +assembly: 0.465 +graphic: 0.456 +vnc: 0.452 +mistranslation: 0.401 +semantic: 0.397 +socket: 0.392 +other: 0.374 +boot: 0.361 + +Plugin deadlock with qemu_plugin_register_vcpu_mem_cb introduced prior to v8.1.0 +Description of problem: +Between v8.0.5 and v8.1.0 a bug was introduced where a TCG plugin calling `qemu_plugin_register_vcpu_mem_cb` can cause a deadlock. This bug is still present in the current head of master (a66f28df650166ae8b50c992eea45e7b247f4143). + +I was able to reproduce this reliably (>95% of the time) testing with the minimal plugin shown below. In more limited testing, I found the logic in the (in-tree) hotpages plugin will also trigger this deadlock. + +I tested with the Ubuntu Bionic qcow from [here](https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2), but don't think there's anything particularly special about this qcow. + + +A minimal plugin to trigger the deadlock is as follows. To build the plugin, you'll need to add a `NAMES += customtest` line into `contrib/plugins/Makefile. + +contrib/plugins/customtest.c: +``` +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info, + uint64_t vaddr, void *udata) +{} + + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + struct qemu_plugin_insn *insn; + size_t n = qemu_plugin_tb_n_insns(tb); + + for (size_t i = 0; i < n; i++) { + insn = qemu_plugin_tb_get_insn(tb, i); + + /* Register callback on memory read or write */ + qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem, + QEMU_PLUGIN_CB_NO_REGS, + QEMU_PLUGIN_MEM_R, NULL); + } +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, int argc, + char **argv) +{ + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + + return 0; +} +``` +Steps to reproduce: +1. From the current head of `master` (a66f28df650166ae8b50c992eea45e7b247f4143) +2. Add the above plugin to the contrib/plugins directory and update the `contrib/plugins/Makefile` with `NAMES += customtest` so it will be built. +3. `../configure --enable-plugins --target-list=x86_64-softmmu` +4. `make && make plugins` +5. `wget https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2` +6. Launch the guest with `./qemu-system-x86_64 -m 1G -plugin contrib/plugins/libcustomtest.so bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2 -nographic -d plugin`, and wait a moment. There will be no output after the initial "Booting from Hard Disk" mesasge. Switch to the monitor with `ctrl+a c` type `quit` and press enter, qemu fails to exit because of the deadlock. +Additional information: +* I tested and saw the bug on the following commits/tags: current head of master (a66f28df650166ae8b50c992eea45e7b247f4143), v9.1.0, v9.0.0, and v8.2.6, v8.1.0. +* I tested and saw no bug on the following tags: v8.0.5, v8.0.4, v8.0.0 +* If `qemu_plugin_register_vcpu_mem_cb` is called with a fourth argument of `0` instead of `QEMU_PLUGIN_MEM_R`, the guest did not hang (at least on the current head of master). +* The monitor can still be reached with `ctrl+a c` after the deadlock, but running the `quit` command does not terminate the emulator (I don't think this is related to #1195 since things start hanging before the shutdown begins) + +Gdb shows the following backtraces (from the head of master) across the running threads. It seems that thread 3 and thread 2 are stuck, though I'm not too familiar with what they're doing. +``` +(gdb) thread apply all bt + +Thread 3 (Thread 0x7f9677fff640 (LWP 754761) "qemu-system-x86"): +#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:57 +#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:87 +#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55a9c1047748 <exclusive_cond+40>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 +#3 0x00007f968280aa41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, cond=0x55a9c1047720 <exclusive_cond>) at ./nptl/pthread_cond_wait.c:503 +#4 ___pthread_cond_wait (cond=cond@entry=0x55a9c1047720 <exclusive_cond>, mutex=mutex@entry=0x55a9c1047660 <qemu_cpu_list_lock>) at ./nptl/pthread_cond_wait.c:627 +#5 0x000055a9bff8ce9f in qemu_cond_wait_impl (cond=0x55a9c1047720 <exclusive_cond>, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, file=0x55a9bffc37b6 "../cpu-common.c", line=221) at ../util/qemu-thread-posix.c:225 +#6 0x000055a9bf8fc7b7 in start_exclusive () at ../cpu-common.c:221 +#7 start_exclusive () at ../cpu-common.c:192 +#8 0x000055a9bfc2f981 in ptw_setl_slow (new=23069091, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:112 +#9 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:130 +#10 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:121 +#11 mmu_translate (env=env@entry=0x55a9c2ab3bc0, in=in@entry=0x7f9677ffa5f0, out=out@entry=0x7f9677ffa5c0, err=err@entry=0x7f9677ffa5d0, ra=ra@entry=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:412 +#12 0x000055a9bfc2fe4f in get_physical_address (ra=<optimized out>, err=<optimized out>, out=<optimized out>, mmu_idx=<optimized out>, access_type=<optimized out>, addr=25041848, env=<optimized out>) at ../target/i386/tcg/sysemu/excp_helper.c:583 +#13 x86_cpu_tlb_fill (cs=0x55a9c2ab1400, addr=25041848, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=5, probe=<optimized out>, retaddr=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:603 +#14 0x000055a9bfd92a59 in tlb_fill (retaddr=140283034940586, mmu_idx=5, access_type=MMU_DATA_LOAD, size=<optimized out>, addr=25041848, cpu=0x55a9c2ab1450) at ../accel/tcg/cputlb.c:1237 +#15 mmu_lookup1 (cpu=cpu@entry=0x55a9c2ab1400, data=data@entry=0x7f9677ffa750, mmu_idx=5, access_type=access_type@entry=MMU_DATA_LOAD, ra=ra@entry=140283034940586) at ../accel/tcg/cputlb.c:1634 +#16 0x000055a9bfd92b71 in mmu_lookup (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=ra@entry=140283034940586, type=type@entry=MMU_DATA_LOAD, l=l@entry=0x7f9677ffa750) at ../accel/tcg/cputlb.c:1724 +#17 0x000055a9bfd937b0 in do_ld4_mmu (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=140283034940586, ra@entry=37, access_type=access_type@entry=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2356 +#18 0x000055a9bfd96afa in cpu_ldl_mmu (ra=37, oi=37, addr=25041848, env=0x55a9c2ab3bc0) at ../accel/tcg/ldst_common.c.inc:160 +#19 cpu_ldl_le_mmuidx_ra (env=env@entry=0x55a9c2ab3bc0, addr=25041848, mmu_idx=mmu_idx@entry=5, ra=ra@entry=140283034940586) at ../accel/tcg/ldst_common.c.inc:298 +#20 0x000055a9bfc9a639 in popl (sa=<synthetic pointer>) at ../target/i386/tcg/seg_helper.c:88 +#21 helper_ret_protected (env=0x55a9c2ab3bc0, shift=1, is_iret=0, addend=0, retaddr=140283034940586) at ../target/i386/tcg/seg_helper.c:2031 +#22 0x00007f96307734aa in code_gen_buffer () +#23 0x000055a9bfd855f6 in cpu_tb_exec (cpu=cpu@entry=0x55a9c2ab1400, itb=itb@entry=0x7f96307733c0 <code_gen_buffer+7811987>, tb_exit=tb_exit@entry=0x7f9677ffadd8) at ../accel/tcg/cpu-exec.c:458 +#24 0x000055a9bfd85b4c in cpu_loop_exec_tb (tb_exit=0x7f9677ffadd8, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f96307733c0 <code_gen_buffer+7811987>, cpu=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:908 +#25 cpu_exec_loop (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1022 +#26 0x000055a9bfd86351 in cpu_exec_setjmp (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1039 +#27 0x000055a9bfd86b0e in cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:1065 +#28 0x000055a9bfdaafa4 in tcg_cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops.c:78 +#29 0x000055a9bfdab0ff in mttcg_cpu_thread_fn (arg=arg@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#30 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 +#31 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#32 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 + +Thread 2 (Thread 0x7f967d990640 (LWP 754759) "qemu-system-x86"): +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055a9bff8d5b2 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /home/user/git/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0x55a9c1079588 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464 +#3 0x000055a9bff97d82 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:278 +#4 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 +#5 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#6 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 + +Thread 1 (Thread 0x7f967dc035c0 (LWP 754758) "qemu-system-x86"): +#0 0x00007f968288fcce in __ppoll (fds=0x55a9c382dd00, nfds=5, timeout=<optimized out>, timeout@entry=0x7ffeadbd44d0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 +#1 0x000055a9bffa4e05 in ppoll (__ss=0x0, __timeout=0x7ffeadbd44d0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=54822346) at ../util/qemu-timer.c:351 +#3 0x000055a9bffa1ed6 in os_host_main_loop_wait (timeout=54822346) at ../util/main-loop.c:305 +#4 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589 +#5 0x000055a9bfb47217 in qemu_main_loop () at ../system/runstate.c:826 +#6 0x000055a9bfee421b in qemu_default_main () at ../system/main.c:37 +#7 0x00007f96827a0d90 in __libc_start_call_main (main=main@entry=0x55a9bf8f9790 <main>, argc=argc@entry=9, argv=argv@entry=0x7ffeadbd46e8) at ../sysdeps/nptl/libc_start_call_main.h:58 +#8 0x00007f96827a0e40 in __libc_start_main_impl (main=0x55a9bf8f9790 <main>, argc=9, argv=0x7ffeadbd46e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeadbd46d8) at ../csu/libc-start.c:392 +#9 0x000055a9bf8fa7b5 in _start () +``` diff --git a/results/classifier/105/KVM/2567 b/results/classifier/105/KVM/2567 new file mode 100644 index 00000000..adba5b0d --- /dev/null +++ b/results/classifier/105/KVM/2567 @@ -0,0 +1,91 @@ +KVM: 0.514 +other: 0.505 +device: 0.474 +semantic: 0.467 +assembly: 0.465 +graphic: 0.455 +boot: 0.453 +mistranslation: 0.433 +vnc: 0.432 +instruction: 0.407 +network: 0.343 +socket: 0.323 + +crash in target/i386/tcg/translate.c on loongarch64 Linux debian 6.11.0-rc7 +Description of problem: +``` + ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached + Bail out! ERROR:target/i386/tcg/translate.c:748:gen_helper_out_func: code should not be reached + 已中止（核心已转储） + ``` +Steps to reproduce: +1. windows x64 has been installed into win7_x64.qcow2 +2. windows x64 in win7_x64.qcow2 has been run for several times by the same command line +3. crash occurred when windows was starting up +Additional information: +``` +Hint: You are currently not seeing messages from other users and the system. + Users in groups 'adm', 'systemd-journal' can see all messages. + Pass -q to turn off this notice. + PID: 61627 (qemu-system-x86) + UID: 1000 (tsingkong) + GID: 1001 (tsingkong) + Signal: 6 (ABRT) + Timestamp: Tue 2024-09-10 15:59:05 CST (18h ago) + Command Line: qemu-system-x86_64 -name win7_x64 -hda /SATA/QEMU/win7_x64.qcow2 -boot c -cpu qemu64 -smp sockets=1,cores=4,threads=1 -m 8G -device VGA -netdev user,id=lan -device rtl8139,netdev=lan -usb -device usb-tablet -rtc base=localtime -monitor stdio + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope + Unit: user@1000.service + User Unit: app-org.kde.konsole-353cf168c0a84fbe8cdc2b8b72cba71e.scope + Slice: user-1000.slice + Owner UID: 1000 (tsingkong) + Boot ID: 49cf5288d7af4b97be341fe599f0c8df + Machine ID: 3ab0590011874c2e916d2eeef4585dfb + Hostname: debian + Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst (present) + Size on Disk: 285.9M + Message: Process 61627 (qemu-system-x86) of user 1000 dumped core. + + Module libsystemd.so.0 from deb systemd-256.5-2.loong64 + Module libgcc_s.so.1 from deb gcc-14-14.2.0-4.loong64 + Module libstdc++.so.6 from deb gcc-14-14.2.0-4.loong64 + Module libblkid.so.1 from deb util-linux-2.40.2-8.loong64 + Module libatomic.so.1 from deb gcc-14-14.2.0-4.loong64 + Module libmount.so.1 from deb util-linux-2.40.2-8.loong64 + Module libzstd.so.1 from deb libzstd-1.5.6+dfsg-1.loong64 + Module libudev.so.1 from deb systemd-256.5-2.loong64 + Stack trace of thread 61637: + #0 0x00007ffff2536968 __pthread_kill_implementation (libc.so.6 + 0x76968) + #1 0x00007ffff24f17dc __GI_raise (libc.so.6 + 0x317dc) + #2 0x00007ffff24dd238 __GI_abort (libc.so.6 + 0x1d238) + #3 0x00007ffff2ccf704 g_assertion_message (libglib-2.0.so.0 + 0x93704) + #4 0x00007ffff2ccf768 g_assertion_message_expr (libglib-2.0.so.0 + 0x93768) + #5 0x000055555630c440 n/a (qemu-system-x86_64 + 0x830440) + #6 0x00005555563286e8 n/a (qemu-system-x86_64 + 0x84c6e8) + #7 0x000055555632ef0c n/a (qemu-system-x86_64 + 0x852f0c) + #8 0x00005555563f9108 translator_loop (qemu-system-x86_64 + 0x91d108) + #9 0x0000555556332474 gen_intermediate_code (qemu-system-x86_64 + 0x856474) + #10 0x00005555563f7c08 n/a (qemu-system-x86_64 + 0x91bc08) + #11 0x00005555563f8204 tb_gen_code (qemu-system-x86_64 + 0x91c204) + #12 0x00005555563ecd54 n/a (qemu-system-x86_64 + 0x910d54) + #13 0x00005555563ed288 n/a (qemu-system-x86_64 + 0x911288) + #14 0x00005555563edb98 cpu_exec (qemu-system-x86_64 + 0x911b98) + #15 0x00007fffdc006c5c tcg_cpu_exec (accel-tcg-x86_64.so + 0x2c5c) + #16 0x00007fffdc006df4 n/a (accel-tcg-x86_64.so + 0x2df4) + #17 0x0000555556636000 n/a (qemu-system-x86_64 + 0xb5a000) + #18 0x00007ffff2534ca4 start_thread (libc.so.6 + 0x74ca4) + #19 0x00007ffff259cbcc __thread_start3 (libc.so.6 + 0xdcbcc) + + Stack trace of thread 61640: + #0 0x00005555563fd620 n/a (qemu-system-x86_64 + 0x921620) + #1 0x0000555556401b44 get_page_addr_code_hostp (qemu-system-x86_64 + 0x925b44) + #2 0x00005555563ebda8 n/a (qemu-system-x86_64 + 0x90fda8) + #3 0x00005555563ed5f0 helper_lookup_tb_ptr (qemu-system-x86_64 + 0x9115f0) + #4 0x00007fff8d39309c n/a (n/a + 0x0) + ELF object binary architecture: LoongArch + +``` + +core.qemu-system-x86.1000.49cf5288d7af4b97be341fe599f0c8df.61627.1725955145000000.zst + +https://mega.nz/file/M9ZVzQYS#Z8kw6_cul56nd_p2iwz2SRb4Yb_1K8gqH2YlBBjKk6U diff --git a/results/classifier/105/KVM/2573 b/results/classifier/105/KVM/2573 new file mode 100644 index 00000000..2527791d --- /dev/null +++ b/results/classifier/105/KVM/2573 @@ -0,0 +1,22 @@ +instruction: 0.992 +KVM: 0.980 +device: 0.873 +vnc: 0.789 +graphic: 0.704 +boot: 0.559 +semantic: 0.555 +socket: 0.455 +network: 0.376 +other: 0.303 +mistranslation: 0.273 +assembly: 0.033 + +RISC-V: Executing floating point instruction in VS mode under KVM acceleration leads to crash +Description of problem: +Executing `fcvt.d.w fa5,a5` in VS mode leads to crash. +Steps to reproduce: +1. Download the Ubuntu 24.10 image https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oracular-preinstalled-server-riscv64.img.xz +2. On your amd64 system launch a VM using -accel tcg +3. Inside the VM launch a new VM using -accel kvm with the payload mentioned above +Additional information: +For more details see https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2077731 diff --git a/results/classifier/105/KVM/2589 b/results/classifier/105/KVM/2589 new file mode 100644 index 00000000..7eb4ed30 --- /dev/null +++ b/results/classifier/105/KVM/2589 @@ -0,0 +1,69 @@ +KVM: 0.756 +graphic: 0.753 +other: 0.747 +instruction: 0.728 +boot: 0.719 +semantic: 0.712 +device: 0.711 +assembly: 0.707 +vnc: 0.641 +mistranslation: 0.633 +network: 0.606 +socket: 0.513 + +Support guest shutdown of Alpine Linux in guest agent +Description of problem: +The qemu-guest-agent's shutdown calls `/sbin/shutdown` with the apropriate flags to shut down a posix system. On Alpine Linux, which is based on busybox, there is no `/sbin/shutdown`, instead there are `/sbin/poweroff`, `/sbin/halt` and `/sbin/reboot`. We have used a downstream patch for years that will exec those as a fallback in case execing `/sbin/shutdown` fails. + +With qemu 9.2 this patch no longer applies and it is probably time to solve this properly in upstream qemu. + +The question is how? + +Some options: + +- Set the powerdown, halt and reboot commands via build time configure option +- Add a fallback if the `execlp` fails (similar to what downstream Alpine's patch does now). We could for example give `ga_run_command` a `const char **argv[]`, and try `execvp` all of them before erroring out. +- Test the existence of `/sbin/shutdown` before calling `ga_run_command`. +- Do nothing. Let downstream Alpine Linux handle it. +Steps to reproduce: +1. Build qemu-guest-agent for Alpine Linux +2. boot a Alpine linux VM and install the qemu-guest-agent +3. Try shutdown the VM via qmp command. +Additional information: +The patch that we previously used that no longer applies: +```diff +diff --git a/qga/commands-posix.c b/qga/commands-posix.c +index 954efed01..61427652c 100644 +--- a/qga/commands-posix.c ++++ b/qga/commands-posix.c +@@ -84,6 +84,7 @@ static void ga_wait_child(pid_t pid, int *status, Error **errp) + void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp) + { + const char *shutdown_flag; ++ const char *fallback_cmd = NULL; + Error *local_err = NULL; + pid_t pid; + int status; +@@ -101,10 +102,13 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp) + slog("guest-shutdown called, mode: %s", mode); + if (!has_mode || strcmp(mode, "powerdown") == 0) { + shutdown_flag = powerdown_flag; ++ fallback_cmd = "/sbin/poweroff"; + } else if (strcmp(mode, "halt") == 0) { + shutdown_flag = halt_flag; ++ fallback_cmd = "/sbin/halt"; + } else if (strcmp(mode, "reboot") == 0) { + shutdown_flag = reboot_flag; ++ fallback_cmd = "/sbin/reboot"; + } else { + error_setg(errp, + "mode is invalid (valid values are: halt|powerdown|reboot"); +@@ -125,6 +129,7 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp) + #else + execl("/sbin/shutdown", "shutdown", "-h", shutdown_flag, "+0", + "hypervisor initiated shutdown", (char *)NULL); ++ execle(fallback_cmd, fallback_cmd, (char*)NULL, environ); + #endif + _exit(EXIT_FAILURE); + } else if (pid < 0) { +``` diff --git a/results/classifier/105/KVM/2631 b/results/classifier/105/KVM/2631 new file mode 100644 index 00000000..4e318db2 --- /dev/null +++ b/results/classifier/105/KVM/2631 @@ -0,0 +1,94 @@ +KVM: 0.889 +instruction: 0.882 +device: 0.881 +graphic: 0.863 +vnc: 0.861 +assembly: 0.852 +mistranslation: 0.843 +other: 0.838 +semantic: 0.827 +boot: 0.816 +socket: 0.776 +network: 0.774 + +qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Description of problem: +While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality. +Steps to reproduce: +Here is qtest reproducer: +```bash +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +``` + +and execution log: +``` +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +[I 0.000001] OPENED +[R +0.067760] outl 0xcf8 0x80001020 +[S +0.067795] OK +OK +[R +0.067821] outl 0xcfc 0xe0800000 +[S +0.067959] OK +OK +[R +0.067993] outl 0xcf8 0x80001004 +[S +0.068005] OK +OK +[R +0.068020] outw 0xcfc 0x02 +[S +0.068520] OK +OK +[R +0.068554] write 0xe0800010 0x4 0x6100 +qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Aborted +``` + +If you need more information, let me know so I can discuss more about this issue. +Additional information: +```c +int msix_init(PCIDevice *dev, unsigned short nentries, + MemoryRegion *table_bar, uint8_t table_bar_nr, + unsigned table_offset, MemoryRegion *pba_bar, + uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos, + Error **errp); +int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries, + uint8_t bar_nr, Error **errp); +``` + +`msix_init` accepts `nentries` as `unsigned short` type. + +```c +static void virtio_pci_device_plugged(DeviceState *d, Error **errp): + + ... + + if (proxy->nvectors) { + int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors, + proxy->msix_bar_idx, NULL); + if (err) { + /* Notice when a system that supports MSIx can't initialize it */ + if (err != -ENOTSUP) { + warn_report("unable to init msix vectors to %" PRIu32, + proxy->nvectors); + } + proxy->nvectors = 0; + } + } +``` + +When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`. +This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash. + +While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration. diff --git a/results/classifier/105/KVM/26430026 b/results/classifier/105/KVM/26430026 new file mode 100644 index 00000000..8db2ac74 --- /dev/null +++ b/results/classifier/105/KVM/26430026 @@ -0,0 +1,173 @@ +KVM: 0.919 +mistranslation: 0.915 +semantic: 0.904 +device: 0.904 +assembly: 0.896 +vnc: 0.893 +instruction: 0.888 +graphic: 0.862 +boot: 0.841 +socket: 0.817 +other: 0.813 +network: 0.758 + +[BUG] cxl,i386: e820 mappings may not be correct for cxl + +Context included below from prior discussion + - `cxl create-region` would fail on inability to allocate memory + - traced this down to the memory region being marked RESERVED + - E820 map marks the CXL fixed memory window as RESERVED + + +Re: x86 errors, I found that region worked with this patch. (I also +added the SRAT patches the Davidlohr posted, but I do not think they are +relevant). + +I don't think this is correct, and setting this to E820_RAM causes the +system to fail to boot at all, but with this change `cxl create-region` +succeeds, which suggests our e820 mappings in the i386 machine are +incorrect. + +Anyone who can help or have an idea as to what e820 should actually be +doing with this region, or if this is correct and something else is +failing, please help! + + +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +index 566accf7e6..a5e688a742 100644 +--- a/hw/i386/pc.c ++++ b/hw/i386/pc.c +@@ -1077,7 +1077,7 @@ void pc_memory_init(PCMachineState *pcms, + memory_region_init_io(&fw->mr, OBJECT(machine), &cfmws_ops, fw, + "cxl-fixed-memory-region", fw->size); + memory_region_add_subregion(system_memory, fw->base, &fw->mr); +- e820_add_entry(fw->base, fw->size, E820_RESERVED); ++ e820_add_entry(fw->base, fw->size, E820_NVS); + cxl_fmw_base += fw->size; + cxl_resv_end = cxl_fmw_base; + } + + +On Mon, Oct 10, 2022 at 05:32:42PM +0100, Jonathan Cameron wrote: +> +> +> > but i'm not sure of what to do with this info. We have some proof +> +> > that real hardware works with this no problem, and the only difference +> +> > is that the EFI/bios/firmware is setting the memory regions as `usable` +> +> > or `soft reserved`, which would imply the EDK2 is the blocker here +> +> > regardless of the OS driver status. +> +> > +> +> > But I'd seen elsewhere you had gotten some of this working, and I'm +> +> > failing to get anything working at the moment. If you have any input i +> +> > would greatly appreciate the help. +> +> > +> +> > QEMU config: +> +> > +> +> > /opt/qemu-cxl2/bin/qemu-system-x86_64 \ +> +> > -drive +> +> > file=/var/lib/libvirt/images/cxl.qcow2,format=qcow2,index=0,media=d\ +> +> > -m 2G,slots=4,maxmem=4G \ +> +> > -smp 4 \ +> +> > -machine type=q35,accel=kvm,cxl=on \ +> +> > -enable-kvm \ +> +> > -nographic \ +> +> > -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52 \ +> +> > -device cxl-rp,id=rp0,bus=cxl.0,chassis=0,slot=0 \ +> +> > -object memory-backend-file,id=cxl-mem0,mem-path=/tmp/cxl-mem0,size=256M \ +> +> > -object memory-backend-file,id=lsa0,mem-path=/tmp/cxl-lsa0,size=256M \ +> +> > -device cxl-type3,bus=rp0,pmem=true,memdev=cxl-mem0,lsa=lsa0,id=cxl-pmem0 +> +> > \ +> +> > -M cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.size=256M +> +> > +> +> > I'd seen on the lists that you had seen issues with single-rp setups, +> +> > but no combination of configuration I've tried (including all the ones +> +> > in the docs and tests) lead to a successful region creation with +> +> > `cxl create-region` +> +> +> +> Hmm. Let me have a play. I've not run x86 tests for a while so +> +> perhaps something is missing there. +> +> +> +> I'm carrying a patch to override check_last_peer() in +> +> cxl_port_setup_targets() as that is wrong for some combinations, +> +> but that doesn't look like it's related to what you are seeing. +> +> +I'm not sure if it's relevant, but turned out I'd forgotten I'm carrying 3 +> +patches that aren't upstream (and one is a horrible hack). +> +> +Hack: +https://lore.kernel.org/linux-cxl/20220819094655.000005ed@huawei.com/ +> +Shouldn't affect a simple case like this... +> +> +https://lore.kernel.org/linux-cxl/20220819093133.00006c22@huawei.com/T/#t +> +(Dan's version) +> +> +https://lore.kernel.org/linux-cxl/20220815154044.24733-1-Jonathan.Cameron@huawei.com/T/#t +> +> +For writes to work you will currently need two rps (nothing on the second is +> +fine) +> +as we still haven't resolved if the kernel should support an HDM decoder on +> +a host bridge with one port. I think it should (Spec allows it), others +> +unconvinced. +> +> +Note I haven't shifted over to x86 yet so may still be something different +> +from +> +arm64. +> +> +Jonathan +> +> + diff --git a/results/classifier/105/KVM/2650 b/results/classifier/105/KVM/2650 new file mode 100644 index 00000000..7636eba1 --- /dev/null +++ b/results/classifier/105/KVM/2650 @@ -0,0 +1,205 @@ +KVM: 0.548 +other: 0.538 +instruction: 0.527 +device: 0.506 +semantic: 0.491 +graphic: 0.490 +boot: 0.486 +socket: 0.465 +vnc: 0.464 +assembly: 0.464 +network: 0.443 +mistranslation: 0.408 + +qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed +Description of problem: +If a named dirty bitmap already exists on a disk and another disk is added via hotplug after the guest has booted, it will definitely cause the hot migration to fail. +Steps to reproduce: +1. Create 2 images of type qcow2 + + ``` + qemu-img create -f qcow2 vda.qcow2 50G + qemu-img create -f qcow2 vdb.qcow2 2G # set to 2G + ``` +2. Start the guest using the following libvirt xml + + ``` + # virsh create i-btacsctt.xml + + <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm"> + <name>i-btacsctt</name> + <uuid>973f7352-ad1d-31ea-9a9f-237f3e9a384f</uuid> + <memory unit="MiB">2048</memory> + <vcpu current="2">2</vcpu> + <os> + <type arch="x86_64" machine="pc">hvm</type> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <devices> + <emulator>/opt/qemu-5.1.0.9/usr/bin/qemu-system-x86_64</emulator> + <disk device="disk" type="file"> + <driver cache="writeback" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vda.qcow2"/> + <target dev="vda"/> + </disk> + <disk device="disk" type="file"> + <driver cache="none" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdb.qcow2"/> + <target dev="vdb"/> + </disk> + </devices> + </domain> + ``` +3. Create bitmap for vda + + ``` + # The node name of vda is "libvirt-2-format" + virsh qemu-monitor-command i-btacsctt --hmp "info block" + libvirt-2-format: /tmp/echohu3/vda.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk0/virtio-backend + Cache mode: writethrough + + libvirt-1-format: /tmp/echohu3/vdb.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk1/virtio-backend + Cache mode: writeback, direct + + # Create bitmap + virsh qemu-monitor-command i-btacsctt '{"execute":"block-dirty-bitmap-add","arguments":{"node":"libvirt-2-format","name":"bitmap0","persistent":true}}' + ``` +4. Create vdc and run hotpluggin + + ``` + qemu-img create -f qcow2 vdc.qcow2 50G + + cat disk.xml + <disk device="disk" type="file"> + <driver cache="none" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdc.qcow2"/> + <target dev="vdc"/> + </disk> + + virsh attach-device i-btacsctt disk.xml + ``` +5. Start live migrationg + + ``` + # scp *.qcow2 172.31.68.42:/tmp/echohu3/ + virsh qemu-monitor-command i-btacsctt --hmp "migrate_set_capability dirty-bitmaps on" + virsh dumpxml --migratable i-btacsctt >/tmp/ivm-btacsctt.xml + virsh migrate --live --abort-on-error --xml /tmp/ivm-btacsctt.xml i-btacsctt qemu+tcp://172.31.68.42/system + error: internal error: qemu unexpectedly closed the monitor: qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed. + ``` +Additional information: +Set breakpoints on the source side + +``` +gdb -p $pid -ex "break add_bitmaps_to_list" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 add_bitmaps_to_list (bs=bs@entry=0x55c5bbaf85d0, bs_name=0x55c5bbafc674 "libvirt-2-format", alias_map=alias_map@entry=0x0, s=<optimized out>) at migration/block-dirty-bitmap.c:502 +#1 0x000055c5ba3b2878 in init_dirty_bitmap_migration (s=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:660 +#2 dirty_bitmap_save_setup (f=0x55c5bc981c40, opaque=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:1226 +#3 0x000055c5ba3a3c4d in qemu_savevm_state_setup (f=0x55c5bc981c40) at migration/savevm.c:1176 +#4 0x000055c5ba39e16b in migration_thread (opaque=opaque@entry=0x55c5bbaa2400) at migration/migration.c:3487 +#5 0x000055c5ba530cf3 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007f39846d9609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007f3983d11293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +(gdb) p bs->node_name +$4 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p bitmap->name +$5 = 0x55c5bbaf13d0 "bitmap0" +``` + +Set a breakpoint on the target side after hitting the breakpoint on the source side. + +``` +gdb -p $pid -ex "break serialization_chunk if ((start + count - 1) >> hb->granularity) >= hb->size" -ex "break dirty_bitmap_load_header" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 dirty_bitmap_load_header (alias_map=0x0, s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:1146 +#1 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1187 +#2 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#3 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#4 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#5 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#6 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#7 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#8 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#9 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +``` + +in dirty_bitmap_load_header + +``` +s->bs = bdrv_lookup_bs(s->node_name, s->node_name, &local_err); // node_name is "libvirt-2-format" +s->bitmap = bdrv_find_dirty_bitmap(s->bs, s->bitmap_name); // bitmap_name is "bitmap0" + +# Target side: “libvirt-2-format” is the node name of vdb. +(gdb) p s->bs->node_name +$10 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p s->bs->filename +$11 = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times> +``` + +We can also see from the target /var/log/libvirt/qemu/i-btacsctt.log file that “libvirt-2-format” is the node name of the vdb，while the node name of vda is libvirt-3-format. + +``` +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vda.qcow2","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"discard":"ignore","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x2,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdb.qcow2","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdc.qcow2","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"ignore","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +``` + +From the source code, we know that HBitmap.size is from vdb size (2G), but bitmap is from vda (50G), so it triggers assert exception in serialization_chunk. + +``` +(gdb) bt +#0 serialization_chunk (hb=hb@entry=0x55748ba28470, start=2147483648, count=536870912, first_el=first_el@entry=0x7f53503ffd20, el_count=el_count@entry=0x7f53503ffd18) at util/hbitmap.c:610 +#1 0x0000557487f18654 in hbitmap_deserialize_zeroes (hb=0x55748ba28470, start=start@entry=2147483648, count=count@entry=536870912, finish=finish@entry=false) at util/hbitmap.c:701 +#2 0x0000557487e7cfb0 in bdrv_dirty_bitmap_deserialize_zeroes (bitmap=<optimized out>, offset=offset@entry=2147483648, bytes=bytes@entry=536870912, finish=finish@entry=false) at block/dirty-bitmap.c:749 +#3 0x0000557487d86b51 in dirty_bitmap_load_bits (s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:992 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +#5 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#6 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#7 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#8 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#9 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#10 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#11 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#12 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +#13 0x00007ffffb29c410 in () +#14 0x0000000000000000 in () +(gdb) p *hb +$16 = {orig_size = 2147483648, size = 32768, count = 0, granularity = 16, meta = 0x0, levels = {0x55748ad55ad0, 0x55748acd8df0, 0x55748b0866a0, 0x55748acf8c10, 0x55748b1c4180, 0x55748b154f60, 0x55748adf2370}, sizes = {1, 1, 1, 1, 1, 8, + 512}} +``` + +``` +(gdb) f 4 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +(gdb) p *s->bs +$21 = {open_flags = 10274, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x557488aa2ee0 <bdrv_qcow2>, opaque = 0x55748acf8c90, aio_context = 0x55748acd1080, + aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing_file = '\000' <repeats 4095 times>, auto_backing_file = '\000' <repeats 4095 times>, + backing_format = '\000' <repeats 15 times>, full_open_options = 0x55748b3c68e0, exact_filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing = 0x0, file = 0x55748aa5de40, bl = {request_alignment = 1, + max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0, + supported_zero_flags = 260, supported_truncate_flags = 2, node_name = "libvirt-2-format", '\000' <repeats 15 times>, node_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0e8}}, + bs_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0f8}}, monitor_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d108}}, refcnt = 2, + op_blockers = {{lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x55748aa5de40}, parents = {lh_first = 0x55748bbc0380}, options = 0x55748ad4d2d0, explicit_options = 0x55748ad525a0, + detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 4194304, before_write_notifiers = {notifiers = {lh_first = 0x0}}, write_threshold_offset = 0, write_threshold_notifier = {notify = 0x0, node = { + le_next = 0x0, le_prev = 0x0}}, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 39 times>, __align = 0}, initialized = true}, dirty_bitmaps = {lh_first = 0x55748b4655f0}, wr_highest_offset = {value = 0}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, io_plugged = 0, + enable_write_cache = 0, quiesce_counter = 0, recursive_quiesce_counter = 0, write_gen = 0, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0}, + tracked_requests = {lh_first = 0x0}, flush_queue = {entries = {sqh_first = 0x0, sqh_last = 0x55748ad52570}}, active_flush_req = false, flushed_gen = 0, never_freeze = false} +``` + +When we merge into commit https://gitlab.com/qemu-project/qemu/-/commit/31e4c354b38cd42a051ad030eb7779d5e7ee32fe and then run `block-bitmap-mapping` before migration, the hot migration can be completed successfully. I would like to confirm with the community whether this solution is reasonable and if there are any other solutions to address this issue. + +``` +virsh qemu-monitor-command i-btacsctt '{"execute": "migrate-set-parameters", "arguments":{"block-bitmap-mapping":[{"node-name":"libvirt-2-format", "alias":"libvirt-3-format","bitmaps":[{"name":"bitmap0", "alias":"bitmap0"}]}]}}' +``` diff --git a/results/classifier/105/KVM/2658 b/results/classifier/105/KVM/2658 new file mode 100644 index 00000000..37d7524f --- /dev/null +++ b/results/classifier/105/KVM/2658 @@ -0,0 +1,14 @@ +KVM: 0.953 +device: 0.743 +instruction: 0.543 +network: 0.452 +graphic: 0.307 +boot: 0.287 +semantic: 0.183 +mistranslation: 0.075 +vnc: 0.048 +assembly: 0.048 +other: 0.016 +socket: 0.007 + +How to simulate the L2MERRSR_EL1 register in KVM mode？ diff --git a/results/classifier/105/KVM/2692 b/results/classifier/105/KVM/2692 new file mode 100644 index 00000000..94190622 --- /dev/null +++ b/results/classifier/105/KVM/2692 @@ -0,0 +1,14 @@ +KVM: 0.980 +instruction: 0.922 +device: 0.799 +network: 0.635 +socket: 0.570 +assembly: 0.333 +graphic: 0.319 +semantic: 0.290 +boot: 0.219 +other: 0.129 +vnc: 0.128 +mistranslation: 0.097 + +Using the ldp instruction to access the I/O address space in KVM mode causes an exception diff --git a/results/classifier/105/KVM/2779 b/results/classifier/105/KVM/2779 new file mode 100644 index 00000000..7ebee813 --- /dev/null +++ b/results/classifier/105/KVM/2779 @@ -0,0 +1,54 @@ +KVM: 0.698 +other: 0.696 +graphic: 0.662 +device: 0.583 +instruction: 0.578 +vnc: 0.572 +semantic: 0.562 +mistranslation: 0.545 +network: 0.500 +socket: 0.491 +boot: 0.490 +assembly: 0.465 + +Segmentation fault when introspecting machine properties +Description of problem: +QEMU currrently crashes when trying to list the properties of the q35 machine type while QEMU has been started with the i440fx machine type. Introspecting QOM objects for their properties should always be possible, but apparently there is currently something causing a crash in this case. +Steps to reproduce: +1. Start QEMU with: qemu-system-x86_64 -M pc -qmp stdio +2. Enter these commands in the QMP monitor: + +``` + { "execute": "qmp_capabilities" } + { "execute": "qom-list-properties","arguments": { "typename": "pc-q35-10.0-machine"}} +``` +Additional information: +Backtrace looks like this: +``` +mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +738 s->cmos_data[addr] = val; +--Type <RET> for more, q to quit, c to continue without paging--#0 mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +#1 0x0000555555bf15d2 in pc_machine_done (notifier=0x555557f40750, data=<optimized out>) at ../../devel/qemu/hw/i386/pc.c:632 +#2 0x0000555555d4f7a2 in object_init_with_type (obj=obj@entry=0x555557f40320, ti=ti@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:424 +#3 0x0000555555d49c7e in object_initialize_with_type (obj=0x555557f40320, size=<optimized out>, type=type@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:570 +#4 0x0000555555d4a660 in object_new_with_type (type=0x5555579c3c60) at ../../devel/qemu/qom/object.c:774 +#5 object_new (typename=typename@entry=0x555558672b30 "pc-q35-10.0-machine") at ../../devel/qemu/qom/object.c:789 +#6 0x0000555555e825c5 in qmp_qom_list_properties (typename=0x555558672b30 "pc-q35-10.0-machine", errp=errp@entry=0x7fffffffd988) + at ../../devel/qemu/qom/qom-qmp-cmds.c:205 +#7 0x0000555555ef0525 in qmp_marshal_qom_list_properties (args=<optimized out>, ret=0x7fffeda9af00, errp=0x7fffeda9af08) + at qapi/qapi-commands-qom.c:288 +#8 0x0000555555f1edc1 in do_qmp_dispatch_bh (opaque=0x7fffeda9aed0) at ../../devel/qemu/qapi/qmp-dispatch.c:128 +#9 0x0000555555f40e28 in aio_bh_poll (ctx=ctx@entry=0x5555579f2930) at ../../devel/qemu/util/async.c:219 +#10 0x0000555555f2886f in aio_dispatch (ctx=0x5555579f2930) at ../../devel/qemu/util/aio-posix.c:424 +#11 0x0000555555f41cbb in aio_ctx_dispatch (source=0x0, callback=0x5f, user_data=<optimized out>) at ../../devel/qemu/util/async.c:361 +#12 0x00007ffff6d98e8c in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0 +#13 0x00007ffff6d99155 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#14 0x0000555555f42540 in glib_pollfds_poll () at ../../devel/qemu/util/main-loop.c:287 +#15 os_host_main_loop_wait (timeout=<optimized out>) at ../../devel/qemu/util/main-loop.c:310 +#16 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../devel/qemu/util/main-loop.c:589 +#17 0x0000555555ae1207 in qemu_main_loop () at ../../devel/qemu/system/runstate.c:835 +#18 0x0000555555e85d57 in qemu_default_main (opaque=<optimized out>) at ../../devel/qemu/system/main.c:48 +#19 0x0000555555e85d2f in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:76 +``` diff --git a/results/classifier/105/KVM/2927 b/results/classifier/105/KVM/2927 new file mode 100644 index 00000000..709b60fa --- /dev/null +++ b/results/classifier/105/KVM/2927 @@ -0,0 +1,184 @@ +KVM: 0.715 +graphic: 0.685 +device: 0.667 +socket: 0.659 +vnc: 0.657 +instruction: 0.650 +semantic: 0.626 +mistranslation: 0.621 +other: 0.615 +assembly: 0.607 +boot: 0.596 +network: 0.486 + +Getting bare metal code running on tricore +Description of problem: +My code is stuck in +Steps to reproduce: +1. Open Infineon Aurix Development Studio (on Windows) +2. Compile project (two examples that I've tested) +a) New -> Project -> Board -> KIT_AURIX_TC277_TFT_DC-Step -> Build +b) the example from here: https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Blinky_LED_1_KIT_TC277_TFT +3. Copy the elf and run qemu on the debian system +Additional information: +When running a blank binary on QEMU with the TriCore TC27x target, the CPU starts executing at address 0x80000020 and enters an infinite loop. +The code seems to be stuck and waiting for some hardware signal. The binary (sample.elf) from this issue qemu-project/qemu#1363 works. + +I know it's probably a rookie problem, but what am I missing? How can I get an example from Infineon running? Or any other example? + +Please let me know if you need additional information! + +```:~/qemu$ ./build/qemu-system-tricore -M KIT_AURIX_TC277_TRB -cpu tc27x -nographic -kernel ../qemu-examples/aurix_tricore_example_bins/Blank_project_TC277.elf -d in_asm +QEMU 9.2.50 monitor - type 'help' for more information +(qemu) ---------------- +IN: _START +0x80000020: +OBJD-T: 91000028d9220681dc02 + +---------------- +IN: _Core0_start +0x80001206: +OBJD-T: 9130002f192200469120003737026e21d92200468ff2838180321b026029602a +OBJD-T: 0d0080043b009820cd42e00f + +---------------- +IN: _Core0_start +0x8000120a: +OBJD-T: 19220046 + +---------------- +IN: _Core0_start +0x8000120e: +OBJD-T: 9120003737026e21d92200468ff2838180321b026029602a0d0080043b009820 +OBJD-T: cd42e00f + +---------------- +IN: _Core0_start +0x80001232: +OBJD-T: 4d00e02fb7021420cd02e00f8212cd4220094dc0e12f8f720021012203260122 +OBJD-T: 02265422542337026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001254: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001256: +OBJD-T: 542337026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001256: +OBJD-T: 5423 + +---------------- +IN: _Core0_start +0x80001258: +OBJD-T: 37026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001264: +OBJD-T: 8f2200305422b7021020a6328f224021742254226f02ffff + +---------------- +IN: _Core0_start +0x80001268: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x8000126a: +OBJD-T: b7021020a6328f224021742254226f02ffff + +---------------- +IN: _Core0_start +0x80001274: +OBJD-T: 7422 + +---------------- +IN: _Core0_start +0x80001276: +OBJD-T: 54226f02ffff + +---------------- +IN: _Core0_start +0x80001276: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001278: +OBJD-T: 6f02ffff + +---------------- +IN: _Core0_start +0x8000127c: +OBJD-T: 8202cdc2200954226f120900 + +---------------- +IN: _Core0_start +0x80001282: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001284: +OBJD-T: 6f120900 + +---------------- +IN: _Core0_start +0x80001296: +OBJD-T: 5422b7021020a6328f324021742254226f02ff7f + +---------------- +IN: _Core0_start +0x80001296: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001298: +OBJD-T: b7021020a6328f324021742254226f02ff7f + +---------------- +IN: _Core0_start +0x800012a2: +OBJD-T: 7422 + +---------------- +IN: _Core0_start +0x800012a4: +OBJD-T: 54226f02ff7f + +---------------- +IN: _Core0_start +0x800012a4: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x800012a6: +OBJD-T: 6f02ff7f + + +(qemu) q +``` + +When I run it with the `-d in_asm,cpu,exec` flag it logs this infinitely often: +``` +Trace 0: 0x7fb5205e9940 [00000000/00000000800012a4/00000002/ff011001] _Core0_start +PC: 800012a4 PSW: 00000980 ICR: 00000000 +PCXI: 00000000 FCX: 00000000 LCX: 00000000 +GPR A00: 00000000 00000000 f0036100 70020000 +GPR A04: 00000000 00000000 00000000 00000000 +GPR A08: 00000000 00000000 70019600 00000000 +GPR A12: 00000000 00000000 00000000 00000000 +GPR D00: 00000000 00000000 00000000 000000fc +GPR D04: 00000000 00000000 00000000 00000000 +GPR D08: 0000003f 00000000 00000000 00000000 +GPR D12: 00000000 00000000 00000000 00000000 +cpu_io_recompile: rewound execution of TB to 00000000800012a4 +``` diff --git a/results/classifier/105/KVM/2950 b/results/classifier/105/KVM/2950 new file mode 100644 index 00000000..e4786294 --- /dev/null +++ b/results/classifier/105/KVM/2950 @@ -0,0 +1,78 @@ +KVM: 0.542 +mistranslation: 0.538 +other: 0.461 +device: 0.454 +vnc: 0.454 +boot: 0.434 +semantic: 0.427 +graphic: 0.423 +network: 0.421 +assembly: 0.412 +instruction: 0.406 +socket: 0.396 + +QEMU 10 breaks Incus' NVME handling +Description of problem: +Incus is an open-source container and VM manager. +For VMs we naturally use QEMU where we basically: + - Use QMP as much as possible to put together the VM prior to starting emulation + - Put the static pre-start stuff in a config file + use readconfig + - Keep the command line to a bare minimum + +This isn't particularly relevant to this issue except for the first point which is our use of QMP for most device handling. That means qemu is spawned without any disk or network attached. We have a `virtio-scsi` controller in the base config file but that's it. + +When doing NVME, we hotplug a new drive and a new nvme device pointing to that drive. +This means that our setup has a 1:1 mapping between NVME controllers on the PCIe bus and drives. + +This worked great up until QEMU 10. With QEMU 10, I believe this commit https://gitlab.com/qemu-project/qemu/-/commit/cd59f50ab017183805a0dd82f5e85159ecc355ce by @birkelund now effectively causes the creation of a `nvme-subsys` device when we add a `nvme` device without a pre-existing subsystem. + +As `nvme-subsys` doesn't support hotplugging, this immediately breaks all our VMs that rely on NVME. + +``` +stgraber@dakara:~$ incus start test-nvme +Error: Failed setting up device via monitor: Failed adding block device for disk device "root": Failed adding device: Device 'nvme-subsys' does not support hotplugging +Try `incus info --show-log test-nvme` for more info +``` + +As you can see, QEMU returns `Device 'nvme-subsys' does not support hotplugging`. + +On the QMP front, we did: +``` +stgraber@dakara:~$ sudo cat /var/log/incus/test-nvme/qemu.qmp.log +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"qom-get","arguments":{"path":"/machine","property":"type"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": "pc-q35-10.0-machine"} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-cpus-fast"} +[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"thread-id": 3885061, "props": {"core-id": 0, "thread-id": 0, "node-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"netdev_add","arguments":{"fds":"/dev/net/tun.0:/dev/net/tun.1","id":"incus_eth0","type":"tap","vhost":true,"vhostfds":"/dev/vhost-net.0:/dev/vhost-net.1"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":1,"bus":"qemu_pcie4","driver":"virtio-net-pci","id":"dev-incus_eth0","mac":"10:66:6a:30:97:66","mq":true,"netdev":"incus_eth0","vectors":6}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-add","arguments":{"aio":"native","cache":{"direct":true,"no-flush":false},"discard":"unmap","driver":"host_device","filename":"/dev/fdset/0","locking":"off","node-name":"incus_root","read-only":false}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":0,"bus":"qemu_pcie5","drive":"incus_root","driver":"nvme","id":"dev-incus_root","serial":"incus_root"}} +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"blockdev-del","arguments":{"node-name":"incus_root"}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"query-fdsets"} +[2025-05-06T11:42:30-04:00] REPLY: {"return": [{"fds": [{"fd": 49, "opaque": "rdwr:incus_root"}], "fdset-id": 0}]} + +[2025-05-06T11:42:30-04:00] QUERY: {"execute":"remove-fd","arguments":{"fdset-id":0}} +[2025-05-06T11:42:30-04:00] REPLY: {"return": {}} +``` +Additional information: +My limited understanding of NVME concepts is that NVME controllers are tied to a subsystem, then drives are tied to namespaces which themselves are tied to subsystems. + +So in a world where we need to deal with QEMU not supporting hotplugging subsystems, we would be able to create a single subsystem with a single controller and then hot plug/remove drives+namespaces into that. + +I've not actually tested this because to us it's not really an option. +We have users that for better or for worse currently rely on the current behavior of having each drive have its own controller, and so on the Linux side expect to see one PCIe device per drive and then one `/dev/nvmeXn1` device per drive. + +Changing this to be multiple namespaces on controller 0 would break anyone who ever hardcoded /dev/nvmeXn1 on their system and may also lead to different performance characteristics due to now using a single controller. Multiple controllers would still be an option of course, but they'd be tied to the same subsystem and namespaces so effectively now having the guest do NVME multipath. + + +Anyway, let me know if I'm missing a way to get QEMU 10 to behave as we did in releases prior, where I can start a VM with 0 NVME controllers, then add a couple of drives, each showing up as their own controller with the drive as namespace 1 on that. diff --git a/results/classifier/105/KVM/391880 b/results/classifier/105/KVM/391880 new file mode 100644 index 00000000..684b81e2 --- /dev/null +++ b/results/classifier/105/KVM/391880 @@ -0,0 +1,27 @@ +KVM: 0.922 +graphic: 0.908 +instruction: 0.862 +device: 0.825 +network: 0.622 +vnc: 0.573 +semantic: 0.547 +other: 0.475 +socket: 0.474 +boot: 0.381 +mistranslation: 0.347 +assembly: 0.036 + +migrate exec hangs for several minutes if the pipe is closed before all its data is written + +Binary package hint: kvm + +Using + + migrate "exec:true" + +in the monitor hangs the VM for several minutes. What I expect is that the VM stops attempting to migrate after the pipe has been closed. + +Indicating a background migrate with -d doesn't help. Presumably the migration is not backgrounded until a certain amount of data is written to the pipe, or the migration times out What I expect is that the migration is backgrounded immediately. + +I can reproduce this in Lucid. Like the other related bug report, I don't have a strong opinion on the feature request, though it seems reasonable. We will defer to Upstream's decision on this one. Thanks! + diff --git a/results/classifier/105/KVM/412 b/results/classifier/105/KVM/412 new file mode 100644 index 00000000..b53775e3 --- /dev/null +++ b/results/classifier/105/KVM/412 @@ -0,0 +1,14 @@ +KVM: 0.871 +device: 0.858 +network: 0.824 +vnc: 0.738 +instruction: 0.726 +boot: 0.531 +graphic: 0.416 +socket: 0.337 +assembly: 0.283 +semantic: 0.221 +other: 0.190 +mistranslation: 0.098 + +stable-5.0 crashes with SIGSEV while checking for kvm extension diff --git a/results/classifier/105/KVM/43643137 b/results/classifier/105/KVM/43643137 new file mode 100644 index 00000000..0ce14b08 --- /dev/null +++ b/results/classifier/105/KVM/43643137 @@ -0,0 +1,546 @@ +KVM: 0.794 +other: 0.781 +semantic: 0.764 +device: 0.760 +instruction: 0.754 +vnc: 0.742 +assembly: 0.727 +graphic: 0.721 +network: 0.709 +socket: 0.674 +mistranslation: 0.665 +boot: 0.652 + +[Qemu-devel] [BUG/RFC] INIT IPI lost when VM starts + +Hi, +We encountered a problem that when a domain starts, seabios failed to online a +vCPU. + +After investigation, we found that the reason is in kvm-kmod, KVM_APIC_INIT bit +in +vcpu->arch.apic->pending_events was overwritten by qemu, and thus an INIT IPI +sent +to AP was lost. Qemu does this since libvirtd sends a âquery-cpusâ qmp command +to qemu +on VM start. + +In qemu, qmp_query_cpus-> cpu_synchronize_state-> kvm_cpu_synchronize_state-> +do_kvm_cpu_synchronize_state, qemu gets registers/vcpu_events from kvm-kmod and +sets cpu->kvm_vcpu_dirty to true, and vcpu thread in qemu will call +kvm_arch_put_registers if cpu->kvm_vcpu_dirty is true, thus pending_events is +overwritten by qemu. + +I think there is no need for qemu to set cpu->kvm_vcpu_dirty to true after +âquery-cpusâ, +and kvm-kmod should not clear KVM_APIC_INIT unconditionally. And I am not sure +whether +it is OK for qemu to set cpu->kvm_vcpu_dirty in do_kvm_cpu_synchronize_state in +each caller. + +Whatâs your opinion? + +Let me clarify it more clearly. Time sequence is that qemu handles âquery-cpusâ qmp +command, vcpu 1 (and vcpu 0) got registers from kvm-kmod (qmp_query_cpus-> +cpu_synchronize_state-> kvm_cpu_synchronize_state-> +> do_kvm_cpu_synchronize_state-> kvm_arch_get_registers), then vcpu 0 (BSP) +sends INIT-SIPI to vcpu 1(AP). In kvm-kmod, vcpu 1âs pending_eventsâs KVM_APIC_INIT +bit set. +Then vcpu 1 continue running, vcpu1 thread in qemu calls +kvm_arch_put_registers-> kvm_put_vcpu_events, so KVM_APIC_INIT bit in vcpu 1âs +pending_events got cleared, i.e., lost. + +In kvm-kmod, except for pending_events, sipi_vector may also be overwritten., +so I am not sure if there are other fields/registers in danger, i.e., those may +be modified asynchronously with vcpu thread itself. + +BTW, using a sleep like following can reliably reproduce this problem, if VM +equipped with more than 2 vcpus and starting VM using libvirtd. + +diff --git a/target/i386/kvm.c b/target/i386/kvm.c +index 55865db..5099290 100644 +--- a/target/i386/kvm.c ++++ b/target/i386/kvm.c +@@ -2534,6 +2534,11 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level) + KVM_VCPUEVENT_VALID_NMI_PENDING | KVM_VCPUEVENT_VALID_SIPI_VECTOR; + } + ++ if (CPU(cpu)->cpu_index == 1) { ++ fprintf(stderr, "vcpu 1 sleep!!!!\n"); ++ sleep(10); ++ } ++ + return kvm_vcpu_ioctl(CPU(cpu), KVM_SET_VCPU_EVENTS, &events); + } + + +On 2017/3/20 22:21, Herongguang (Stephen) wrote: +Hi, +We encountered a problem that when a domain starts, seabios failed to online a +vCPU. + +After investigation, we found that the reason is in kvm-kmod, KVM_APIC_INIT bit +in +vcpu->arch.apic->pending_events was overwritten by qemu, and thus an INIT IPI +sent +to AP was lost. Qemu does this since libvirtd sends a âquery-cpusâ qmp command +to qemu +on VM start. + +In qemu, qmp_query_cpus-> cpu_synchronize_state-> kvm_cpu_synchronize_state-> +do_kvm_cpu_synchronize_state, qemu gets registers/vcpu_events from kvm-kmod and +sets cpu->kvm_vcpu_dirty to true, and vcpu thread in qemu will call +kvm_arch_put_registers if cpu->kvm_vcpu_dirty is true, thus pending_events is +overwritten by qemu. + +I think there is no need for qemu to set cpu->kvm_vcpu_dirty to true after +âquery-cpusâ, +and kvm-kmod should not clear KVM_APIC_INIT unconditionally. And I am not sure +whether +it is OK for qemu to set cpu->kvm_vcpu_dirty in do_kvm_cpu_synchronize_state in +each caller. + +Whatâs your opinion? + +On 20/03/2017 15:21, Herongguang (Stephen) wrote: +> +> +We encountered a problem that when a domain starts, seabios failed to +> +online a vCPU. +> +> +After investigation, we found that the reason is in kvm-kmod, +> +KVM_APIC_INIT bit in +> +vcpu->arch.apic->pending_events was overwritten by qemu, and thus an +> +INIT IPI sent +> +to AP was lost. Qemu does this since libvirtd sends a âquery-cpusâ qmp +> +command to qemu +> +on VM start. +> +> +In qemu, qmp_query_cpus-> cpu_synchronize_state-> +> +kvm_cpu_synchronize_state-> +> +do_kvm_cpu_synchronize_state, qemu gets registers/vcpu_events from +> +kvm-kmod and +> +sets cpu->kvm_vcpu_dirty to true, and vcpu thread in qemu will call +> +kvm_arch_put_registers if cpu->kvm_vcpu_dirty is true, thus +> +pending_events is +> +overwritten by qemu. +> +> +I think there is no need for qemu to set cpu->kvm_vcpu_dirty to true +> +after âquery-cpusâ, +> +and kvm-kmod should not clear KVM_APIC_INIT unconditionally. And I am +> +not sure whether +> +it is OK for qemu to set cpu->kvm_vcpu_dirty in +> +do_kvm_cpu_synchronize_state in each caller. +> +> +Whatâs your opinion? +Hi Rongguang, + +sorry for the late response. + +Where exactly is KVM_APIC_INIT dropped? kvm_get_mp_state does clear the +bit, but the result of the INIT is stored in mp_state. + +kvm_get_vcpu_events is called after kvm_get_mp_state; it retrieves +KVM_APIC_INIT in events.smi.latched_init and kvm_set_vcpu_events passes +it back. Maybe it should ignore events.smi.latched_init if not in SMM, +but I would like to understand the exact sequence of events. + +Thanks, + +paolo + +On 2017/4/6 0:16, Paolo Bonzini wrote: +On 20/03/2017 15:21, Herongguang (Stephen) wrote: +We encountered a problem that when a domain starts, seabios failed to +online a vCPU. + +After investigation, we found that the reason is in kvm-kmod, +KVM_APIC_INIT bit in +vcpu->arch.apic->pending_events was overwritten by qemu, and thus an +INIT IPI sent +to AP was lost. Qemu does this since libvirtd sends a âquery-cpusâ qmp +command to qemu +on VM start. + +In qemu, qmp_query_cpus-> cpu_synchronize_state-> +kvm_cpu_synchronize_state-> +do_kvm_cpu_synchronize_state, qemu gets registers/vcpu_events from +kvm-kmod and +sets cpu->kvm_vcpu_dirty to true, and vcpu thread in qemu will call +kvm_arch_put_registers if cpu->kvm_vcpu_dirty is true, thus +pending_events is +overwritten by qemu. + +I think there is no need for qemu to set cpu->kvm_vcpu_dirty to true +after âquery-cpusâ, +and kvm-kmod should not clear KVM_APIC_INIT unconditionally. And I am +not sure whether +it is OK for qemu to set cpu->kvm_vcpu_dirty in +do_kvm_cpu_synchronize_state in each caller. + +Whatâs your opinion? +Hi Rongguang, + +sorry for the late response. + +Where exactly is KVM_APIC_INIT dropped? kvm_get_mp_state does clear the +bit, but the result of the INIT is stored in mp_state. +It's dropped in KVM_SET_VCPU_EVENTS, see below. +kvm_get_vcpu_events is called after kvm_get_mp_state; it retrieves +KVM_APIC_INIT in events.smi.latched_init and kvm_set_vcpu_events passes +it back. Maybe it should ignore events.smi.latched_init if not in SMM, +but I would like to understand the exact sequence of events. +time0: +vcpu1: +qmp_query_cpus-> cpu_synchronize_state-> kvm_cpu_synchronize_state-> +> do_kvm_cpu_synchronize_state(and set vcpu1's cpu->kvm_vcpu_dirty to true)-> +kvm_arch_get_registers(KVM_APIC_INIT bit in vcpu->arch.apic->pending_events was not set) + +time1: +vcpu0: +send INIT-SIPI to all AP->(in vcpu 0's context)__apic_accept_irq(KVM_APIC_INIT bit +in vcpu1's arch.apic->pending_events is set) + +time2: +vcpu1: +kvm_cpu_exec->(if cpu->kvm_vcpu_dirty is +true)kvm_arch_put_registers->kvm_put_vcpu_events(overwritten KVM_APIC_INIT bit in +vcpu->arch.apic->pending_events!) + +So it's a race between vcpu1 get/put registers with kvm/other vcpus changing +vcpu1's status/structure fields in the mean time, I am in worry of if there are +other fields may be overwritten, +sipi_vector is one. + +also see: +https://www.mail-archive.com/address@hidden/msg438675.html +Thanks, + +paolo + +. + +Hi Paolo, + +What's your opinion about this patch? We found it just before finishing patches +for the past two days. + + +Thanks, +-Gonglei + + +> +-----Original Message----- +> +From: address@hidden [ +mailto:address@hidden +On +> +Behalf Of Herongguang (Stephen) +> +Sent: Thursday, April 06, 2017 9:47 AM +> +To: Paolo Bonzini; address@hidden; address@hidden; +> +address@hidden; address@hidden; address@hidden; +> +wangxin (U); Huangweidong (C) +> +Subject: Re: [BUG/RFC] INIT IPI lost when VM starts +> +> +> +> +On 2017/4/6 0:16, Paolo Bonzini wrote: +> +> +> +> On 20/03/2017 15:21, Herongguang (Stephen) wrote: +> +>> We encountered a problem that when a domain starts, seabios failed to +> +>> online a vCPU. +> +>> +> +>> After investigation, we found that the reason is in kvm-kmod, +> +>> KVM_APIC_INIT bit in +> +>> vcpu->arch.apic->pending_events was overwritten by qemu, and thus an +> +>> INIT IPI sent +> +>> to AP was lost. Qemu does this since libvirtd sends a âquery-cpusâ qmp +> +>> command to qemu +> +>> on VM start. +> +>> +> +>> In qemu, qmp_query_cpus-> cpu_synchronize_state-> +> +>> kvm_cpu_synchronize_state-> +> +>> do_kvm_cpu_synchronize_state, qemu gets registers/vcpu_events from +> +>> kvm-kmod and +> +>> sets cpu->kvm_vcpu_dirty to true, and vcpu thread in qemu will call +> +>> kvm_arch_put_registers if cpu->kvm_vcpu_dirty is true, thus +> +>> pending_events is +> +>> overwritten by qemu. +> +>> +> +>> I think there is no need for qemu to set cpu->kvm_vcpu_dirty to true +> +>> after âquery-cpusâ, +> +>> and kvm-kmod should not clear KVM_APIC_INIT unconditionally. And I am +> +>> not sure whether +> +>> it is OK for qemu to set cpu->kvm_vcpu_dirty in +> +>> do_kvm_cpu_synchronize_state in each caller. +> +>> +> +>> Whatâs your opinion? +> +> Hi Rongguang, +> +> +> +> sorry for the late response. +> +> +> +> Where exactly is KVM_APIC_INIT dropped? kvm_get_mp_state does clear +> +the +> +> bit, but the result of the INIT is stored in mp_state. +> +> +It's dropped in KVM_SET_VCPU_EVENTS, see below. +> +> +> +> +> kvm_get_vcpu_events is called after kvm_get_mp_state; it retrieves +> +> KVM_APIC_INIT in events.smi.latched_init and kvm_set_vcpu_events passes +> +> it back. Maybe it should ignore events.smi.latched_init if not in SMM, +> +> but I would like to understand the exact sequence of events. +> +> +time0: +> +vcpu1: +> +qmp_query_cpus-> cpu_synchronize_state-> kvm_cpu_synchronize_state-> +> +> do_kvm_cpu_synchronize_state(and set vcpu1's cpu->kvm_vcpu_dirty to +> +true)-> kvm_arch_get_registers(KVM_APIC_INIT bit in +> +vcpu->arch.apic->pending_events was not set) +> +> +time1: +> +vcpu0: +> +send INIT-SIPI to all AP->(in vcpu 0's +> +context)__apic_accept_irq(KVM_APIC_INIT bit in vcpu1's +> +arch.apic->pending_events is set) +> +> +time2: +> +vcpu1: +> +kvm_cpu_exec->(if cpu->kvm_vcpu_dirty is +> +true)kvm_arch_put_registers->kvm_put_vcpu_events(overwritten +> +KVM_APIC_INIT bit in vcpu->arch.apic->pending_events!) +> +> +So it's a race between vcpu1 get/put registers with kvm/other vcpus changing +> +vcpu1's status/structure fields in the mean time, I am in worry of if there +> +are +> +other fields may be overwritten, +> +sipi_vector is one. +> +> +also see: +> +https://www.mail-archive.com/address@hidden/msg438675.html +> +> +> Thanks, +> +> +> +> paolo +> +> +> +> . +> +> +> + +2017-11-20 06:57+0000, Gonglei (Arei): +> +Hi Paolo, +> +> +What's your opinion about this patch? We found it just before finishing +> +patches +> +for the past two days. +I think your case was fixed by f4ef19108608 ("KVM: X86: Fix loss of +pending INIT due to race"), but that patch didn't fix it perfectly, so +maybe you're hitting a similar case that happens in SMM ... + +> +> -----Original Message----- +> +> From: address@hidden [ +mailto:address@hidden +On +> +> Behalf Of Herongguang (Stephen) +> +> On 2017/4/6 0:16, Paolo Bonzini wrote: +> +> > Hi Rongguang, +> +> > +> +> > sorry for the late response. +> +> > +> +> > Where exactly is KVM_APIC_INIT dropped? kvm_get_mp_state does clear +> +> the +> +> > bit, but the result of the INIT is stored in mp_state. +> +> +> +> It's dropped in KVM_SET_VCPU_EVENTS, see below. +> +> +> +> > +> +> > kvm_get_vcpu_events is called after kvm_get_mp_state; it retrieves +> +> > KVM_APIC_INIT in events.smi.latched_init and kvm_set_vcpu_events passes +> +> > it back. Maybe it should ignore events.smi.latched_init if not in SMM, +> +> > but I would like to understand the exact sequence of events. +> +> +> +> time0: +> +> vcpu1: +> +> qmp_query_cpus-> cpu_synchronize_state-> kvm_cpu_synchronize_state-> +> +> > do_kvm_cpu_synchronize_state(and set vcpu1's cpu->kvm_vcpu_dirty to +> +> true)-> kvm_arch_get_registers(KVM_APIC_INIT bit in +> +> vcpu->arch.apic->pending_events was not set) +> +> +> +> time1: +> +> vcpu0: +> +> send INIT-SIPI to all AP->(in vcpu 0's +> +> context)__apic_accept_irq(KVM_APIC_INIT bit in vcpu1's +> +> arch.apic->pending_events is set) +> +> +> +> time2: +> +> vcpu1: +> +> kvm_cpu_exec->(if cpu->kvm_vcpu_dirty is +> +> true)kvm_arch_put_registers->kvm_put_vcpu_events(overwritten +> +> KVM_APIC_INIT bit in vcpu->arch.apic->pending_events!) +> +> +> +> So it's a race between vcpu1 get/put registers with kvm/other vcpus changing +> +> vcpu1's status/structure fields in the mean time, I am in worry of if there +> +> are +> +> other fields may be overwritten, +> +> sipi_vector is one. +Fields that can be asynchronously written by other VCPUs (like SIPI, +NMI) must not be SET if other VCPUs were not paused since the last GET. +(Looking at the interface, we can currently lose pending SMI.) + +INIT is one of the restricted fields, but the API unconditionally +couples SMM with latched INIT, which means that we can lose an INIT if +the VCPU is in SMM mode -- do you see SMM in kvm_vcpu_events? + +Thanks. + diff --git a/results/classifier/105/KVM/498 b/results/classifier/105/KVM/498 new file mode 100644 index 00000000..74528592 --- /dev/null +++ b/results/classifier/105/KVM/498 @@ -0,0 +1,55 @@ +KVM: 0.394 +mistranslation: 0.287 +vnc: 0.283 +graphic: 0.261 +instruction: 0.174 +other: 0.148 +boot: 0.133 +assembly: 0.125 +device: 0.118 +semantic: 0.109 +network: 0.085 +socket: 0.068 + +Cannot focus QEMU window on macOS Big Sur (11.4) +Description of problem: +I'm not sure when the problem has been started, but I recently noticed that key inputs to QEMU window are not processed and the input goes other focused windows (e.g. terminal). QEMU window itself is shown but it looks like they are not focused. Also, the Dock icon for QEMU is also disappeared (it was displayed before). +Steps to reproduce: +1. build & install the latest qemu with `./configure --target-list=x86_64-softmmu` + - (`a146af86c8247f41b641783428b95ee71eb0e43f` was the revision I used) +2. run `qemu-system-x86_64` from terminal +3. click the QEMU window. + - Expected behavior: menu bar title will be switched to "QEMU", key inputs are handled by QEMU, Dock icon will be shown. + - Actual behavior: menu bar shows different app name that were focused before clicking the qemu, key inputs went to other app that was focused, dock icon is not showing up. +Additional information: +I tried to see if the events are delivered to QemuCocoaView by putting `NSLog(@"handleEventLocked: %@\n", event);` at the beginning of `handleEventLocked` @ `ui/cocoa.m`. It looks like the mouse events are delivered but not NSEventTypeKeyDown. + +(logs after clicked the QEMU window and type some 'a') +``` +$ qemu-system-x86_64 +2021-07-24 16:58:00.767 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682409.7 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=4 data1=1144258560 data2=1138098176 +2021-07-24 16:58:00.768 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,228) time=682409.7 flags=0 win=0x7fe2b5fb0ee0 winNum=10356 ctxt=0x0 subtype=4 data1=1137180672 data2=1130627072 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1129 data2=0 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(591.031,166.896) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,0) time=0.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=1 data1=1129 data2=0 +2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=22 data1=0 data2=0 +2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=23 data1=0 data2=0 +2021-07-24 16:58:06.565 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(591.031,166.896) time=682415.5 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:12.997 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(174.184,408.859) time=682421.9 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:13.013 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(152.704,428.804) time=682422.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1131 data2=0 +2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(268.333,208.222) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:24.262 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(268.333,208.222) time=682433.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:24.877 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(3.83252,400.359) time=682433.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 +2021-07-24 16:58:25.053 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1 +2021-07-24 16:58:25.054 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0 +2021-07-24 16:58:25.302 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(10.917,420.558) time=682434.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0 +2021-07-24 16:58:25.365 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(10.917,420.558) time=682434.3 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0 +2021-07-24 16:58:25.845 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1 +2021-07-24 16:58:25.846 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0 +2021-07-24 16:58:25.855 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(14.2417,428.558) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0 + +``` + +Possibly related discussion on Apple Developer Forums: +- https://developer.apple.com/forums/thread/667004 diff --git a/results/classifier/105/KVM/504368 b/results/classifier/105/KVM/504368 new file mode 100644 index 00000000..972552c9 --- /dev/null +++ b/results/classifier/105/KVM/504368 @@ -0,0 +1,191 @@ +KVM: 0.755 +other: 0.750 +mistranslation: 0.710 +instruction: 0.688 +graphic: 0.684 +vnc: 0.675 +network: 0.659 +socket: 0.654 +assembly: 0.651 +semantic: 0.646 +device: 0.641 +boot: 0.634 + +sdl window intermittently scales instead of resizing + +Binary package hint: qemu-kvm + +Normally, the SDL output window for a VM resizes to match the VM's resolution. However, intermittently the output is instead scaled within the window. I can't seem to find any pattern to when the output is scaled versus when the window is resized. I would prefer that the window be resized as needed to display the VM in a 1:1 manner. + +ProblemType: Bug +Architecture: amd64 +Date: Thu Jan 7 10:30:10 2010 +DistroRelease: Ubuntu 9.10 +InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027) +KvmCmdLine: + UID PID PPID C SZ RSS PSR STIME TTY TIME CMD + root 27618 1 38 241752 804668 1 10:05 ? 00:09:39 /usr/bin/kvm -S -M pc-0.11 -cpu qemu32 -m 768 -smp 1 -name win2k3 -uuid da414aa0-f18a-7a02-3d1b-1dbf13137bc9 -monitor unix:/var/run/libvirt/qemu/win2k3.monitor,server,nowait -localtime -boot c -drive file=/media/qpc-devel/testing/win2k3/testing.ovl,if=ide,index=0,boot=on -drive file=/media/qpc-devel/testing/win2k3/../../isos/en_win_srv_2003_r2_standard_cd1.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:d6:f5:60,vlan=0,model=ne2k_pci,name=ne2k_pci.0 -net tap,fd=18,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vga cirrus + root 28306 1 54 177732 545520 1 10:28 ? 00:00:49 /usr/bin/kvm -S -M pc-0.11 -cpu qemu32 -m 512 -smp 1 -name win2k -uuid 153d6125-acb5-70bc-c7d2-bcbf87c5be86 -monitor unix:/var/run/libvirt/qemu/win2k.monitor,server,nowait -localtime -boot c -drive file=/media/qpc-devel/testing/win2k/testing.ovl,if=ide,index=0,boot=on -drive file=/media/qpc-devel/testing/win2k/../../isos/windows_2000.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=68:29:6b:13:50:c6,vlan=0,model=ne2k_pci,name=ne2k_pci.0 -net tap,fd=19,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vga cirrus +NonfreeKernelModules: nvidia +Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3 +PccardctlIdent: + Socket 0: + no product info available +PccardctlStatus: + Socket 0: + no card +ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-16-generic root=UUID=30218f9a-6f90-4eab-9ba5-f54897e842cb ro quiet splash +ProcEnviron: + PATH=(custom, user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: Ubuntu 2.6.31-16.53-generic +SourcePackage: qemu-kvm +Uname: Linux 2.6.31-16-generic x86_64 +dmi.bios.date: 02/20/2008 +dmi.bios.vendor: LENOVO +dmi.bios.version: 7LETB2WW (2.12 ) +dmi.board.vendor: LENOVO +dmi.board.version: Not Available +dmi.chassis.asset.tag: No Asset Information +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Not Available +dmi.modalias: dmi:bvnLENOVO:bvr7LETB2WW(2.12):bd02/20/2008:svnLENOVO:pn:pvrThinkPadT61p:rvnLENOVO:rn:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: +dmi.product.version: ThinkPad T61p +dmi.sys.vendor: LENOVO + + + +Reported upstream also: https://sourceforge.net/tracker/?func=detail&aid=2930756&group_id=180599&atid=893831 + +Anthony, can you explain the behavior here? + +At the very least, we should be able to get something into the documentation. + +On Karmic (qemu-kvm-0.11) I noticed some strange behavior. If I physically "moved" the window before X was fully up in the guest, the image would be scaled in a strange way. + +I do not see this behavior in Lucid's qemu-kvm 0.12.3. Jamin, do you? + +If you accidentally resize the window (even by 1-pixel), then it will stay in scaled mode even during guest geometry changes. + +It sucks from a usability perspective. Clever suggestions about how we can support scaling in a more friendly way are certainly appreciated. + +@Dustin, +I've experienced the problem with a rebuild of the lucid package for karmic. The package is in my PPA, https://launchpad.net/~jcollins/+archive/jaminppa. + +@Anthony, +I can assure you that I've seen the scaling without resizing the client window in any way. Simply starting the VM and leaving it untouched periodically results in a scaled display. + +On Wed, Mar 3, 2010 at 8:03 AM, Jamin W. Collins +<email address hidden> wrote: +> @Anthony, +> I can assure you that I've seen the scaling without resizing the client window in any way. Simply starting the VM and leaving it untouched periodically results in a scaled display. + +Jamin- + +What about 'moving' the client window? I have not seen it rescale at +random, but I have seen it rescale if I move the window before X comes +up. + +I frequently relocate my VM displays. My host system's window manager is openbox. Normally, for moving any window about my screen, I utilize the ALT+left-click feature to drag the window about. This has the added benefit of ensuring I don't accidentally resize the window. + +Most of my guests are Windows based at the moment. When the display scales it tends to remain the size of the booting splash screen. + +I just tried some different methods of starting the VMs and dragging the displays about. If I'm performing an ALT+left-click drag when the display wants to resize it seems to switch to scaling instead. So, this may be part of it, but I am very certain I've seen the same result when simply starting the VM and not touching the display in any way. + +Just had it happen again. Simply started the VM, didn't touch the SDL window for it at all, guest wound up scaled. Here's the xwininfo output for the SDL window: + +xwininfo: Window id: 0x6e00003 "QEMU (winxp-work)" + + Absolute upper-left X: 640 + Absolute upper-left Y: 367 + Relative upper-left X: 1 + Relative upper-left Y: 20 + Width: 720 + Height: 480 + Depth: 24 + Visual Class: DirectColor + Border width: 0 + Class: InputOutput + Colormap: 0x6e0000c (not installed) + Bit Gravity State: ForgetGravity + Window Gravity State: NorthWestGravity + Backing Store State: NotUseful + Save Under State: no + Map State: IsViewable + Override Redirect State: no + Corners: +640+367 -560+367 -560-353 +640-353 + -geometry 720x480+639+347 + + +You can disable scaling by hitting ctrl-alt-u. + +What's probably happening is that the window manager is generating an extraneous scaling event. I'm going to move this to wishlist as we should provide better user controls of this behavior. + +My window manager maximizes all windows. I am running kvm 0.14. + +Initially the VM is displayed 1:1 in the top left corner leaving large portion of the window black. Resizing the window or rebooting the VM causes the output to be scaled which is horrendous. + +There are three issues here: there is no way to force the window to be the size of the VM output nor is there a way to display the VM output 1:1 regardless of window size nor is there any possibility to make the VM output scale proportionally. + +Pressing Ctrl+Alt+u definitely does not disable scaling for me although it causes the VM output to disappear momentarily causing the window to flash. + +I guess setting window size can be achieved with some WM hint (and should be a command line option and possibly a option configurable from the monitor). Obviously, not all outputs can set the hint and not all WMs will respect it. However, setting the hint *and* resizing to the desired size should give the correct size in most cases. http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#NORESIZE + +The other issue is that scaling does not respect aspect ratio leading to horrendous VM output. I don't think there is any use case for non-proportional scaling. + + + +I have the same problem too. Anything other than each guest pixel mapping to exactly one host pixel looks bad. There should be a way to ensure that this is always the case (in fact, perhaps it should be the default and there should be a command line switch to allow the possibility of the display being scaled). + +VirtualBox gets this right. + +This may be the root cause of bug 986192 + +I have attached a screenshot that shows the *contents* of a SDL window *not* being scaled despite the window being maximized. Is this the same issue or not? If not, can you attach a screenshot describing the issue? + +On 26 April 2012 18:23, Serge Hallyn <email address hidden> wrote: +> This may be the root cause of bug 986192 + +I guess not. That bug is TwinView specific but this issue happens with +any graphics. + +In fact, in qemu 1.5 this issue is no longer present. + + +As requested here's a screenshot of the scaled window. The expected behavior is that the window be resized to the dimensions of the guest. + +Pressing Ctrl+Alt+u within this window corrects the issue and the window is in fact resized to the guest dimensions. + +Scaling can be triggered by: + +- Pressing ctrl-alt-{minus,plus} (on certain keyboard layouts) +- a SDL_VIDEORESIZE event + +SDL_VIDEORESIZE is always sent on an X ConfigureNotify event when a SDL_VideoSurface is active. (SDL_VideoSurface is NULL if a resize was done in SDL_SetVideoMode). + +So it really must be a window manager or something sending this resize event. What WM are you using? + +Notes, SDL_VIDEORESIZE (and other events) may be eaten: +- in the very early start-up stage[1] (causing the issue mentioned in comment 13) +- during switches to and from fullscreen +- (some other paths that do not affect QEMU) + + [1]: http://bugzilla.libsdl.org/show_bug.cgi?id=1859 + +Window manager varies. In the original report it was openbox (as I believe I stated, in comment #7). Current window manager is xfwm4. For the screenshot provided, I intentionally moved the window with Alt+left_click as I knew this would trigger the issue (also indicated in comment #7). However, as stated before, the issue happens seemingly randomly on its own without moving the window or interacting with it in any way. + +I cannot reproduce with KWin FWIW, but have an openbox box somewhere (no pun intended). + +Can you apply the attached debug patch, reproduce your bug (move with alt+click) and attach the output? If the log grows too large, try: + + uniq -f1 -c log +What version of SDL are you using? + +Since support for SDL 1.2 has been removed from QEMU now, can you still reproduce this issue with the latest version of QEMU and SDL2 ? + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/528 b/results/classifier/105/KVM/528 new file mode 100644 index 00000000..8796c4be --- /dev/null +++ b/results/classifier/105/KVM/528 @@ -0,0 +1,14 @@ +KVM: 0.969 +device: 0.816 +instruction: 0.643 +graphic: 0.490 +vnc: 0.424 +boot: 0.366 +semantic: 0.360 +assembly: 0.181 +other: 0.165 +mistranslation: 0.160 +network: 0.131 +socket: 0.068 + +arm: trying to use KVM with an EL3-enabled CPU hits an assertion failure diff --git a/results/classifier/105/KVM/530077 b/results/classifier/105/KVM/530077 new file mode 100644 index 00000000..5872dad8 --- /dev/null +++ b/results/classifier/105/KVM/530077 @@ -0,0 +1,29 @@ +KVM: 0.898 +graphic: 0.810 +instruction: 0.636 +device: 0.589 +semantic: 0.536 +boot: 0.533 +other: 0.415 +socket: 0.359 +network: 0.350 +vnc: 0.281 +mistranslation: 0.255 +assembly: 0.055 + +kvm: 16-bit code execution failure should be more friendly + +Today, when kvm fails at 16-bit code execution, we report: + + spirit:~/qemu> qemu-kvm ./hda-fedora.img + kvm: unhandled exit 80000021 + kvm_run returned -22 + +There are three reasons exit reason 21 happens. The first is that a user is executing an image containing a workload that uses GFXBOOT or some other bootloader that exercises big real mode. On pre-Westmere Intel processors, VT could not handle big real mode. The second reason is that the guest's image is corrupted and we're executing random code. We accidentally fall into one of the unsupported modes for VT. Again, this is addressed on WSM. The third case is where there's an actual bug in KVM. This should be exceedingly rare at this stage. + +We should present a friendly error message explaining the possible causes and recommending corrective action. + +Triaging old bug tickets... has this ever been fixed, thus could we close this ticket nowadays? Or is there something left to do here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/563 b/results/classifier/105/KVM/563 new file mode 100644 index 00000000..50be0848 --- /dev/null +++ b/results/classifier/105/KVM/563 @@ -0,0 +1,14 @@ +KVM: 0.998 +device: 0.974 +boot: 0.597 +graphic: 0.404 +instruction: 0.403 +mistranslation: 0.392 +semantic: 0.316 +socket: 0.262 +vnc: 0.239 +network: 0.203 +assembly: 0.079 +other: 0.037 + +KVM ubuntu 20 VPS on Ryzen 9 5950X diff --git a/results/classifier/105/KVM/584514 b/results/classifier/105/KVM/584514 new file mode 100644 index 00000000..8c9837be --- /dev/null +++ b/results/classifier/105/KVM/584514 @@ -0,0 +1,49 @@ +KVM: 0.913 +device: 0.664 +graphic: 0.585 +semantic: 0.455 +instruction: 0.428 +other: 0.422 +socket: 0.312 +mistranslation: 0.282 +network: 0.264 +vnc: 0.210 +assembly: 0.207 +boot: 0.144 + +Qemu-KVM 0.12.4 Guest entered Paused State + +I recently had a 0.12.4 qemu-kvm with a debian lenny guest which occasionally paused. + +There was no memory exhaustion as suggested earlier. + +qemu-kvm send the following output:: + +VM internal error. Suberror: 1 +rax 0000000000000100 rbx ffff880017585bc0 rcx 00007f84c6d5b000 rdx 0000000000000001 +rsi 0000000000000000 rdi ffff88001d322dec rsp ffff88001e133e88 rbp ffff88001e133e88 +r8 0000000001f25bc2 r9 0000000000000007 r10 00007f84c6b4d97b r11 0000000000000206 +r12 ffff88001d322dec r13 ffff88001d322de8 r14 0000000000000001 r15 0000000000000000 +rip ffffffff81039719 rflags 00010092 +cs 0010 (00000000/ffffffff p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0) +ds 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +es 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +ss 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) +fs 0000 (7f84c6d53700/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gs 0000 (ffff880001d00000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +tr 0040 (ffff880001d13780/00002087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) +ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gdt ffff880001d04000/7f +idt ffffffff8195e000/fff +cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501 +emulation failure, check dmesg for details + +Unfortunately, I found nothing in syslog or dmesg + +How about the qemu process，in which state？ will it be blocking？ + + +QEMU 0.12 is pretty old nowadays - is this issue still reproducible with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/589231 b/results/classifier/105/KVM/589231 new file mode 100644 index 00000000..4645de73 --- /dev/null +++ b/results/classifier/105/KVM/589231 @@ -0,0 +1,27 @@ +KVM: 0.859 +device: 0.837 +graphic: 0.830 +other: 0.735 +instruction: 0.711 +mistranslation: 0.611 +network: 0.606 +semantic: 0.550 +socket: 0.422 +boot: 0.392 +vnc: 0.273 +assembly: 0.158 + +cirrus vga is very slow in qemu-kvm-0.12 + +As has been reported multiple times (*), there were a regression in qemu-kvm from 0.11 to 0.12, which causes significant slowdown in cirrus vga emulation. For windows guests, where "standard VGA" driver works reasonable well, -vga std is a good workaround. But for e.g. linux guests, where vesa driver is painfully slow by its own, that's not a solution. + +(*) + debian qemu-kvm bug report #574988: http://bugs.debian.org/574988#17 + debian qemu bugreport (might be related): http://bugs.debian.org/575720 + kvm mailinglist thread: http://<email address hidden>/msg33459.html + another kvm ml thread: http://<email address hidden>/msg32744.html + +QEMU 0.12 is pretty much outdated - has this been fixed in a newer version of QEMU? I.e. do you think we can close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/599574 b/results/classifier/105/KVM/599574 new file mode 100644 index 00000000..4e644b0e --- /dev/null +++ b/results/classifier/105/KVM/599574 @@ -0,0 +1,30 @@ +KVM: 0.774 +graphic: 0.659 +device: 0.604 +semantic: 0.566 +instruction: 0.521 +network: 0.489 +mistranslation: 0.479 +boot: 0.242 +socket: 0.214 +assembly: 0.168 +vnc: 0.166 +other: 0.140 + +qemu-kvm: -no-reboot option broken in 12.x + +When using the "-no-reboot" qemu option with kvm, qemu does nothing and immediately exits with no output or error message. If I add the --no-kvm option to the command line, it works as expected. + +It works fine in 11.0 and 11.1, but I tested all versions of 12.X, and they all have this problem. + +There is no QEMU version 11.x or 12.x, so I assume this ticket is rather meant for the Ubuntu QEMU package + +Please give the output of: + +which qemu +dpkg -l | egrep -e "(qemu|kvm)" +cat /etc/*-release + + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/612297 b/results/classifier/105/KVM/612297 new file mode 100644 index 00000000..271e4371 --- /dev/null +++ b/results/classifier/105/KVM/612297 @@ -0,0 +1,31 @@ +KVM: 0.879 +mistranslation: 0.867 +device: 0.766 +graphic: 0.763 +network: 0.712 +semantic: 0.707 +other: 0.706 +instruction: 0.690 +boot: 0.684 +socket: 0.494 +assembly: 0.428 +vnc: 0.308 + +qemu-kvm fails to detect mouse while Windows 95 setup + +CPU: AMD Phenom II X4 945 +KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package) +Kernel: linux-2.6.26.8-rt16 +arch: x86_64 +Guest: Windows 95 B + +I'm trying to install Windows 95 B on qemu-kvm with this options: + +kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M -rtc base=localtime -k de -soundhw sb16 -vga cirrus -net user,hostname=w95vm -net nic,model=ne2k_pci -boot a -fda /var/mmn/vm/floppy/win95B_Drive-D-boot.img -cdrom /var/mmn/vm/CD/win95-setup.iso -no-acpi -no-kvm -usb + +I've also tried some other option, but always the same: no ps/2 mouse detection. And usb mouse is not supported by Windows 95 B while setup process. This is only possible later by installing the extension usbsupp.exe after the system setup. + +Seems like you were using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/612452 b/results/classifier/105/KVM/612452 new file mode 100644 index 00000000..134203f5 --- /dev/null +++ b/results/classifier/105/KVM/612452 @@ -0,0 +1,140 @@ +KVM: 0.861 +mistranslation: 0.799 +vnc: 0.724 +instruction: 0.706 +other: 0.695 +device: 0.690 +semantic: 0.650 +assembly: 0.647 +boot: 0.645 +socket: 0.600 +graphic: 0.586 +network: 0.445 + +Problems with the number of serial ports for more than two + +qemu --version +QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard + +Command line: + +qemu -serial null -serial null -serial file:test1 hd.img + +Error: + +isa irq 4 already assigned + +echo $? +1 + +This bug seems to be solved and closed here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051 + +Is it solved in 0.12.5 or 0.13.0rc1 yet? + + +> This bug seems to be solved and closed here: http://bugs.debian.org/cgi- +> bin/bugreport.cgi?bug=574051 +> +> Is it solved in 0.12.5 or 0.13.0rc1 yet? +> +> ** Bug watch added: Debian Bug tracker #574051 +> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051 +> +#cd qemu-snapshot +#date +Fri Sep 17 09:29:01 MSD 2010 +#cat .git/config +... +[remote "origin"] + url = git://git.savannah.nongnu.org/qemu.git + fetch = +refs/heads/*:refs/remotes/origin/* +[branch "master"] + remote = origin + merge = refs/heads/master + +#git pull +... +#./configure --disable-xen --audio-drv-list=alsa,sdl +#make && make install +... +install -m 755 qemu "/usr/local/bin" +... +#ls -l /usr/local/bin/qemu +#-rwxr-xr-x 1 root root 1960900 2010-09-17 09:45 /usr/local/bin/qemu +#/usr/local/bin/qemu --version +QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard +#cd /path/to/hd/image +#/usr/local/bin/qemu -serial file:file1 -serial file:file2 -serial none +-serial none hd.img + +In VM + +#echo test1 >/dev/ttyS0 +#echo test2 >/dev/ttyS1 +#echo test3 >/dev/ttyS2 +... error... +#echo test4 >/dev/ttyS3 +... error... + +It is right + +#halt + + +In host + +#ls -l file* +-rw-r--r-- 1 root root 7 2010-09-17 10:13 file1 +-rw-r--r-- 1 root root 7 2010-09-17 10:12 file2 + + +Excellent. Try next. + +#rm -f file* +#/usr/local/bin/qemu -serial file:file1 -serial file:file2 -serial +file:file3 -serial none hd.img +isa irq 4 already assigned + +Misfire. Try next. + +#/usr/local/bin/qemu -serial none -serial none -serial file:file3 +-serial file:file4 hd.img + +In VM + +#echo test1 >/dev/ttyS0 +#echo test2 >/dev/ttyS1 +#echo test3 >/dev/ttyS2 +... error... +#echo test4 >/dev/ttyS3 +... error... + +OOPS! Surprise. + +#halt + + +In host + +#ls -l file* +-rw-r--r-- 1 root root 7 2010-09-17 10:40 file3 +-rw-r--r-- 1 root root 7 2010-09-17 10:40 file4 + +In this case expected. + + +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/105/KVM/642304 b/results/classifier/105/KVM/642304 new file mode 100644 index 00000000..bcd7eca8 --- /dev/null +++ b/results/classifier/105/KVM/642304 @@ -0,0 +1,59 @@ +KVM: 0.834 +graphic: 0.688 +mistranslation: 0.654 +instruction: 0.634 +device: 0.632 +other: 0.632 +semantic: 0.595 +boot: 0.463 +vnc: 0.348 +socket: 0.322 +network: 0.309 +assembly: 0.275 + +Solaris/x86 v10 hangs under KVM + +Solaris/x86 10 guest hangs when running under KVM with the message "Running Configuration Assistant". It runs fine when -enable-kvm isn't given as a command option. + +Host OS: Linux/x86_64 +Guest OS: Solaris/x86 +Command Line: qemu -hda solaris.img -m 192 -boot c -enable-kvm +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: 58aebb946acff82c62383f350cab593e55cc13dc + +Your bug report doesn't tell us anything about the host system (AMD, Intel, which CPU model etc), +nor which version of KVM you are running, which distro etc? + +Did it work with older versions of qemu-kvm? + +Which version of Solaris/x86 (pointer to version preferably) + +Please provide appropriate information if you want a chance that anyone will look at this. + +Jes + + +1) Host CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz +2) KVM doesn't have specific "versions" on Debian. The kernel is built with KVM included. The kernel is version 2.6.32-5 +3) Debian 5.0 +4) No - it's never worked for me, but I've only just got around to posting the bug +5) 10 + + + +As I mentioned in email reply, _every_ package in almost every distribution (the ones I know anyway), Debian included, has a version number attached. + +The git commit ID (58aebb946acff82c62383f350cab593e55cc13dc) appears to be in qemu or qemu-kvm git tree (it's found on both), somewhere past 0.13.0-rc0 (dated Sep 18 2010). But from this commit ID it's impossible to tell if you're using qemu or qemu-kvm. + +What are you using --enable-io-thread for? + + + + + +1: If you can give instructions on how to get a version number for kvm on Debian I'll follow them. "dpkg -l | fgrep kvm" lists nothing. +2: I'm using the qemu git tree. +3: Why are you asking? Are you saying that enable-io-thread is broken with --enable-kvm? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/645524 b/results/classifier/105/KVM/645524 new file mode 100644 index 00000000..6b6934cf --- /dev/null +++ b/results/classifier/105/KVM/645524 @@ -0,0 +1,25 @@ +KVM: 0.894 +graphic: 0.791 +device: 0.735 +other: 0.614 +mistranslation: 0.550 +semantic: 0.538 +vnc: 0.511 +socket: 0.453 +boot: 0.442 +network: 0.421 +instruction: 0.310 +assembly: 0.257 + +No picture from USB webcam (kvm 0.13-rc1) + +I export my Linux webcam to KVM using the switches "-usb -usbdevice host:046d:0929". The XP guest sees the webcam and the drivers install, but the camera only shows a black image. When I open the camera in Windows Explorer, it says "0 images" and a black image, while on a real XP, it says "1 image" and shows the video from the camera. Same problem with different webcams. Same cameras work fine on a native XP install. + +Thanks for the report. + +Can you tell me if it works with a Linux guest? + +Can you tell me what kind of camera it is (e.g. the descriptors from lsusb -v for the device)? + +Since there hasn't been any response to the question in comment #1, and version 0.13 is very outdated nowadays, I'm closing this ticket now. If you've still got USB problems with the very latest version of QEMU, please feel free to re-open this ticket again, or open a new ticket instead. + diff --git a/results/classifier/105/KVM/71456293 b/results/classifier/105/KVM/71456293 new file mode 100644 index 00000000..4f5d04ac --- /dev/null +++ b/results/classifier/105/KVM/71456293 @@ -0,0 +1,1494 @@ +KVM: 0.691 +mistranslation: 0.659 +vnc: 0.625 +instruction: 0.624 +graphic: 0.603 +assembly: 0.602 +device: 0.601 +semantic: 0.600 +other: 0.598 +boot: 0.598 +socket: 0.596 +network: 0.491 + +[Qemu-devel][bug] qemu crash when migrate vm and vm's disks + +When migrate vm and vmâs disks target host qemu crash due to an invalid free. +#0 object_unref (obj=0x1000) at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/qom/object.c:920 +#1 0x0000560434d79e79 in memory_region_unref (mr=<optimized out>) +at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/memory.c:1730 +#2 flatview_destroy (view=0x560439653880) at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/memory.c:292 +#3 0x000056043514dfbe in call_rcu_thread (opaque=<optimized out>) +at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/util/rcu.c:284 +#4 0x00007fbc2b36fe25 in start_thread () from /lib64/libpthread.so.0 +#5 0x00007fbc2b099bad in clone () from /lib64/libc.so.6 +test base qemu-2.12.0 +ï¼ +but use lastest qemu(v6.0.0-rc2) also reproduce. +As follow patch can resolve this problem: +https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg02272.html +Steps to reproduce: +(1) Create VM (virsh define) +(2) Add 64 virtio scsi disks +(3) migrate vm and vmâdisks +------------------------------------------------------------------------------------------------------------------------------------- +æ¬é®ä»¶åå ¶é件å«ææ°åä¸éå¢çä¿å¯ä¿¡æ¯ï¼ä» éäºåéç»ä¸é¢å°åä¸ååº +ç个人æ群ç»ãç¦æ¢ä»»ä½å ¶ä»äººä»¥ä»»ä½å½¢å¼ä½¿ç¨ï¼å æ¬ä½ä¸éäºå ¨é¨æé¨åå°æ³é²ãå¤å¶ã +ææ£åï¼æ¬é®ä»¶ä¸çä¿¡æ¯ãå¦ææ¨éæ¶äºæ¬é®ä»¶ï¼è¯·æ¨ç«å³çµè¯æé®ä»¶éç¥å件人并å é¤æ¬ +é®ä»¶ï¼ +This e-mail and its attachments contain confidential information from New H3C, which is +intended only for the person or entity whose address is listed above. Any use of the +information contained herein in any way (including, but not limited to, total or partial +disclosure, reproduction, or dissemination) by persons other than the intended +recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender +by phone or email immediately and delete it! + +* Yuchen (yu.chen@h3c.com) wrote: +> +When migrate vm and vmâs disks target host qemu crash due to an invalid free. +> +> +#0 object_unref (obj=0x1000) at +> +/qemu-2.12/rpmbuild/BUILD/qemu-2.12/qom/object.c:920 +> +#1 0x0000560434d79e79 in memory_region_unref (mr=<optimized out>) +> +at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/memory.c:1730 +> +#2 flatview_destroy (view=0x560439653880) at +> +/qemu-2.12/rpmbuild/BUILD/qemu-2.12/memory.c:292 +> +#3 0x000056043514dfbe in call_rcu_thread (opaque=<optimized out>) +> +at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/util/rcu.c:284 +> +#4 0x00007fbc2b36fe25 in start_thread () from /lib64/libpthread.so.0 +> +#5 0x00007fbc2b099bad in clone () from /lib64/libc.so.6 +> +> +test base qemu-2.12.0ï¼but use lastest qemu(v6.0.0-rc2) also reproduce. +Interesting. + +> +As follow patch can resolve this problem: +> +https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg02272.html +That's a pci/rcu change; ccing Paolo and Micahel. + +> +Steps to reproduce: +> +(1) Create VM (virsh define) +> +(2) Add 64 virtio scsi disks +Is that hot adding the disks later, or are they included in the VM at +creation? +Can you provide a libvirt XML example? + +> +(3) migrate vm and vmâdisks +What do you mean by 'and vm disks' - are you doing a block migration? + +Dave + +> +------------------------------------------------------------------------------------------------------------------------------------- +> +æ¬é®ä»¶åå ¶é件å«ææ°åä¸éå¢çä¿å¯ä¿¡æ¯ï¼ä» éäºåéç»ä¸é¢å°åä¸ååº +> +ç个人æ群ç»ãç¦æ¢ä»»ä½å ¶ä»äººä»¥ä»»ä½å½¢å¼ä½¿ç¨ï¼å æ¬ä½ä¸éäºå ¨é¨æé¨åå°æ³é²ãå¤å¶ã +> +ææ£åï¼æ¬é®ä»¶ä¸çä¿¡æ¯ãå¦ææ¨éæ¶äºæ¬é®ä»¶ï¼è¯·æ¨ç«å³çµè¯æé®ä»¶éç¥å件人并å é¤æ¬ +> +é®ä»¶ï¼ +> +This e-mail and its attachments contain confidential information from New +> +H3C, which is +> +intended only for the person or entity whose address is listed above. Any use +> +of the +> +information contained herein in any way (including, but not limited to, total +> +or partial +> +disclosure, reproduction, or dissemination) by persons other than the intended +> +recipient(s) is prohibited. If you receive this e-mail in error, please +> +notify the sender +> +by phone or email immediately and delete it! +-- +Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK + +> +-----é®ä»¶å件----- +> +å件人: Dr. David Alan Gilbert [ +mailto:dgilbert@redhat.com +] +> +åéæ¶é´: 2021å¹´4æ8æ¥ 19:27 +> +æ¶ä»¶äºº: yuchen (Cloud) <yu.chen@h3c.com>; pbonzini@redhat.com; +> +mst@redhat.com +> +æé: qemu-devel@nongnu.org +> +主é¢: Re: [Qemu-devel][bug] qemu crash when migrate vm and vm's disks +> +> +* Yuchen (yu.chen@h3c.com) wrote: +> +> When migrate vm and vmâs disks target host qemu crash due to an invalid +> +free. +> +> +> +> #0 object_unref (obj=0x1000) at +> +> /qemu-2.12/rpmbuild/BUILD/qemu-2.12/qom/object.c:920 +> +> #1 0x0000560434d79e79 in memory_region_unref (mr=<optimized out>) +> +> at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/memory.c:1730 +> +> #2 flatview_destroy (view=0x560439653880) at +> +> /qemu-2.12/rpmbuild/BUILD/qemu-2.12/memory.c:292 +> +> #3 0x000056043514dfbe in call_rcu_thread (opaque=<optimized out>) +> +> at /qemu-2.12/rpmbuild/BUILD/qemu-2.12/util/rcu.c:284 +> +> #4 0x00007fbc2b36fe25 in start_thread () from /lib64/libpthread.so.0 +> +> #5 0x00007fbc2b099bad in clone () from /lib64/libc.so.6 +> +> +> +> test base qemu-2.12.0ï¼but use lastest qemu(v6.0.0-rc2) also reproduce. +> +> +Interesting. +> +> +> As follow patch can resolve this problem: +> +> +https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg02272.html +> +> +That's a pci/rcu change; ccing Paolo and Micahel. +> +> +> Steps to reproduce: +> +> (1) Create VM (virsh define) +> +> (2) Add 64 virtio scsi disks +> +> +Is that hot adding the disks later, or are they included in the VM at +> +creation? +> +Can you provide a libvirt XML example? +> +Include disks in the VM at creation + +vm disks xml (only virtio scsi disks): + <devices> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native'/> + <source file='/vms/tempp/vm-os'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data1'/> + <target dev='sda' bus='scsi'/> + <address type='drive' controller='2' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data2'/> + <target dev='sdb' bus='scsi'/> + <address type='drive' controller='3' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data3'/> + <target dev='sdc' bus='scsi'/> + <address type='drive' controller='4' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data4'/> + <target dev='sdd' bus='scsi'/> + <address type='drive' controller='5' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data5'/> + <target dev='sde' bus='scsi'/> + <address type='drive' controller='6' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data6'/> + <target dev='sdf' bus='scsi'/> + <address type='drive' controller='7' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data7'/> + <target dev='sdg' bus='scsi'/> + <address type='drive' controller='8' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data8'/> + <target dev='sdh' bus='scsi'/> + <address type='drive' controller='9' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data9'/> + <target dev='sdi' bus='scsi'/> + <address type='drive' controller='10' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data10'/> + <target dev='sdj' bus='scsi'/> + <address type='drive' controller='11' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data11'/> + <target dev='sdk' bus='scsi'/> + <address type='drive' controller='12' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data12'/> + <target dev='sdl' bus='scsi'/> + <address type='drive' controller='13' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data13'/> + <target dev='sdm' bus='scsi'/> + <address type='drive' controller='14' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data14'/> + <target dev='sdn' bus='scsi'/> + <address type='drive' controller='15' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data15'/> + <target dev='sdo' bus='scsi'/> + <address type='drive' controller='16' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data16'/> + <target dev='sdp' bus='scsi'/> + <address type='drive' controller='17' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data17'/> + <target dev='sdq' bus='scsi'/> + <address type='drive' controller='18' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data18'/> + <target dev='sdr' bus='scsi'/> + <address type='drive' controller='19' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data19'/> + <target dev='sds' bus='scsi'/> + <address type='drive' controller='20' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data20'/> + <target dev='sdt' bus='scsi'/> + <address type='drive' controller='21' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data21'/> + <target dev='sdu' bus='scsi'/> + <address type='drive' controller='22' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data22'/> + <target dev='sdv' bus='scsi'/> + <address type='drive' controller='23' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data23'/> + <target dev='sdw' bus='scsi'/> + <address type='drive' controller='24' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data24'/> + <target dev='sdx' bus='scsi'/> + <address type='drive' controller='25' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data25'/> + <target dev='sdy' bus='scsi'/> + <address type='drive' controller='26' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data26'/> + <target dev='sdz' bus='scsi'/> + <address type='drive' controller='27' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data27'/> + <target dev='sdaa' bus='scsi'/> + <address type='drive' controller='28' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data28'/> + <target dev='sdab' bus='scsi'/> + <address type='drive' controller='29' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data29'/> + <target dev='sdac' bus='scsi'/> + <address type='drive' controller='30' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data30'/> + <target dev='sdad' bus='scsi'/> + <address type='drive' controller='31' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data31'/> + <target dev='sdae' bus='scsi'/> + <address type='drive' controller='32' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data32'/> + <target dev='sdaf' bus='scsi'/> + <address type='drive' controller='33' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data33'/> + <target dev='sdag' bus='scsi'/> + <address type='drive' controller='34' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data34'/> + <target dev='sdah' bus='scsi'/> + <address type='drive' controller='35' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data35'/> + <target dev='sdai' bus='scsi'/> + <address type='drive' controller='36' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data36'/> + <target dev='sdaj' bus='scsi'/> + <address type='drive' controller='37' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data37'/> + <target dev='sdak' bus='scsi'/> + <address type='drive' controller='38' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data38'/> + <target dev='sdal' bus='scsi'/> + <address type='drive' controller='39' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data39'/> + <target dev='sdam' bus='scsi'/> + <address type='drive' controller='40' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data40'/> + <target dev='sdan' bus='scsi'/> + <address type='drive' controller='41' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data41'/> + <target dev='sdao' bus='scsi'/> + <address type='drive' controller='42' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data42'/> + <target dev='sdap' bus='scsi'/> + <address type='drive' controller='43' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data43'/> + <target dev='sdaq' bus='scsi'/> + <address type='drive' controller='44' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data44'/> + <target dev='sdar' bus='scsi'/> + <address type='drive' controller='45' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data45'/> + <target dev='sdas' bus='scsi'/> + <address type='drive' controller='46' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data46'/> + <target dev='sdat' bus='scsi'/> + <address type='drive' controller='47' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data47'/> + <target dev='sdau' bus='scsi'/> + <address type='drive' controller='48' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data48'/> + <target dev='sdav' bus='scsi'/> + <address type='drive' controller='49' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data49'/> + <target dev='sdaw' bus='scsi'/> + <address type='drive' controller='50' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data50'/> + <target dev='sdax' bus='scsi'/> + <address type='drive' controller='51' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data51'/> + <target dev='sday' bus='scsi'/> + <address type='drive' controller='52' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data52'/> + <target dev='sdaz' bus='scsi'/> + <address type='drive' controller='53' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data53'/> + <target dev='sdba' bus='scsi'/> + <address type='drive' controller='54' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data54'/> + <target dev='sdbb' bus='scsi'/> + <address type='drive' controller='55' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data55'/> + <target dev='sdbc' bus='scsi'/> + <address type='drive' controller='56' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data56'/> + <target dev='sdbd' bus='scsi'/> + <address type='drive' controller='57' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data57'/> + <target dev='sdbe' bus='scsi'/> + <address type='drive' controller='58' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data58'/> + <target dev='sdbf' bus='scsi'/> + <address type='drive' controller='59' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data59'/> + <target dev='sdbg' bus='scsi'/> + <address type='drive' controller='60' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data60'/> + <target dev='sdbh' bus='scsi'/> + <address type='drive' controller='61' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data61'/> + <target dev='sdbi' bus='scsi'/> + <address type='drive' controller='62' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data62'/> + <target dev='sdbj' bus='scsi'/> + <address type='drive' controller='63' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data63'/> + <target dev='sdbk' bus='scsi'/> + <address type='drive' controller='64' bus='0' target='0' unit='0'/> + </disk> + <controller type='scsi' index='0'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x02' +function='0x0'/> + </controller> + <controller type='scsi' index='1' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' +function='0x0'/> + </controller> + <controller type='scsi' index='2' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' +function='0x0'/> + </controller> + <controller type='scsi' index='3' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x03' +function='0x0'/> + </controller> + <controller type='scsi' index='4' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x04' +function='0x0'/> + </controller> + <controller type='scsi' index='5' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x05' +function='0x0'/> + </controller> + <controller type='scsi' index='6' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x06' +function='0x0'/> + </controller> + <controller type='scsi' index='7' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x07' +function='0x0'/> + </controller> + <controller type='scsi' index='8' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x08' +function='0x0'/> + </controller> + <controller type='scsi' index='9' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x09' +function='0x0'/> + </controller> + <controller type='scsi' index='10' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0a' +function='0x0'/> + </controller> + <controller type='scsi' index='11' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0b' +function='0x0'/> + </controller> + <controller type='scsi' index='12' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0c' +function='0x0'/> + </controller> + <controller type='scsi' index='13' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0d' +function='0x0'/> + </controller> + <controller type='scsi' index='14' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0e' +function='0x0'/> + </controller> + <controller type='scsi' index='15' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0f' +function='0x0'/> + </controller> + <controller type='scsi' index='16' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x10' +function='0x0'/> + </controller> + <controller type='scsi' index='17' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x11' +function='0x0'/> + </controller> + <controller type='scsi' index='18' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x12' +function='0x0'/> + </controller> + <controller type='scsi' index='19' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x13' +function='0x0'/> + </controller> + <controller type='scsi' index='20' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x14' +function='0x0'/> + </controller> + <controller type='scsi' index='21' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x15' +function='0x0'/> + </controller> + <controller type='scsi' index='22' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x16' +function='0x0'/> + </controller> + <controller type='scsi' index='23' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x17' +function='0x0'/> + </controller> + <controller type='scsi' index='24' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x18' +function='0x0'/> + </controller> + <controller type='scsi' index='25' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x19' +function='0x0'/> + </controller> + <controller type='scsi' index='26' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1a' +function='0x0'/> + </controller> + <controller type='scsi' index='27' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1b' +function='0x0'/> + </controller> + <controller type='scsi' index='28' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1c' +function='0x0'/> + </controller> + <controller type='scsi' index='29' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1d' +function='0x0'/> + </controller> + <controller type='scsi' index='30' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1e' +function='0x0'/> + </controller> + <controller type='scsi' index='31' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x01' +function='0x0'/> + </controller> + <controller type='scsi' index='32' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x02' +function='0x0'/> + </controller> + <controller type='scsi' index='33' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x03' +function='0x0'/> + </controller> + <controller type='scsi' index='34' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x04' +function='0x0'/> + </controller> + <controller type='scsi' index='35' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x05' +function='0x0'/> + </controller> + <controller type='scsi' index='36' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x06' +function='0x0'/> + </controller> + <controller type='scsi' index='37' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x07' +function='0x0'/> + </controller> + <controller type='scsi' index='38' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x08' +function='0x0'/> + </controller> + <controller type='scsi' index='39' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x09' +function='0x0'/> + </controller> + <controller type='scsi' index='40' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x0a' +function='0x0'/> + </controller> + <controller type='scsi' index='41' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x0b' +function='0x0'/> + </controller> + <controller type='scsi' index='42' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x0c' +function='0x0'/> + </controller> + <controller type='scsi' index='43' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x0d' +function='0x0'/> + </controller> + <controller type='scsi' index='44' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' +function='0x0'/> + </controller> + <controller type='scsi' index='45' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' +function='0x0'/> + </controller> + <controller type='scsi' index='46' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' +function='0x0'/> + </controller> + <controller type='scsi' index='47' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' +function='0x0'/> + </controller> + <controller type='scsi' index='48' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0d' +function='0x0'/> + </controller> + <controller type='scsi' index='49' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0e' +function='0x0'/> + </controller> + <controller type='scsi' index='50' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' +function='0x0'/> + </controller> + <controller type='scsi' index='51' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +function='0x0'/> + </controller> + <controller type='scsi' index='52' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x11' +function='0x0'/> + </controller> + <controller type='scsi' index='53' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x12' +function='0x0'/> + </controller> + <controller type='scsi' index='54' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x13' +function='0x0'/> + </controller> + <controller type='scsi' index='55' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x14' +function='0x0'/> + </controller> + <controller type='scsi' index='56' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x15' +function='0x0'/> + </controller> + <controller type='scsi' index='57' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x16' +function='0x0'/> + </controller> + <controller type='scsi' index='58' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x17' +function='0x0'/> + </controller> + <controller type='scsi' index='59' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x18' +function='0x0'/> + </controller> + <controller type='scsi' index='60' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x19' +function='0x0'/> + </controller> + <controller type='scsi' index='61' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1a' +function='0x0'/> + </controller> + <controller type='scsi' index='62' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' +function='0x0'/> + </controller> + <controller type='scsi' index='63' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1c' +function='0x0'/> + </controller> + <controller type='scsi' index='64' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' +function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='pci' index='1' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' +function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1f' +function='0x0'/> + </controller> + </devices> + +vm disks xml (only virtio disks): + <devices> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native'/> + <source file='/vms/tempp/vm-os'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data2'/> + <target dev='vdb' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data3'/> + <target dev='vdc' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data4'/> + <target dev='vdd' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data5'/> + <target dev='vde' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data6'/> + <target dev='vdf' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0d' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data7'/> + <target dev='vdg' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0e' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data8'/> + <target dev='vdh' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data9'/> + <target dev='vdi' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data10'/> + <target dev='vdj' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x11' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data11'/> + <target dev='vdk' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x12' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data12'/> + <target dev='vdl' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x13' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data13'/> + <target dev='vdm' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x14' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data14'/> + <target dev='vdn' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x15' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data15'/> + <target dev='vdo' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x16' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data16'/> + <target dev='vdp' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x17' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data17'/> + <target dev='vdq' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x18' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data18'/> + <target dev='vdr' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x19' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data19'/> + <target dev='vds' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1a' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data20'/> + <target dev='vdt' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data21'/> + <target dev='vdu' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1c' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data22'/> + <target dev='vdv' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data23'/> + <target dev='vdw' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data24'/> + <target dev='vdx' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data25'/> + <target dev='vdy' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x03' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data26'/> + <target dev='vdz' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x04' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data27'/> + <target dev='vdaa' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x05' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data28'/> + <target dev='vdab' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x06' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data29'/> + <target dev='vdac' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x07' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data30'/> + <target dev='vdad' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x08' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data31'/> + <target dev='vdae' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x09' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data32'/> + <target dev='vdaf' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0a' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data33'/> + <target dev='vdag' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0b' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data34'/> + <target dev='vdah' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0c' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data35'/> + <target dev='vdai' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0d' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data36'/> + <target dev='vdaj' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0e' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data37'/> + <target dev='vdak' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x0f' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data38'/> + <target dev='vdal' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x10' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data39'/> + <target dev='vdam' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x11' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data40'/> + <target dev='vdan' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x12' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data41'/> + <target dev='vdao' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x13' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data42'/> + <target dev='vdap' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x14' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data43'/> + <target dev='vdaq' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x15' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data44'/> + <target dev='vdar' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x16' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data45'/> + <target dev='vdas' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x17' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data46'/> + <target dev='vdat' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x18' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data47'/> + <target dev='vdau' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x19' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data48'/> + <target dev='vdav' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1a' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data49'/> + <target dev='vdaw' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1b' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data50'/> + <target dev='vdax' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1c' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data51'/> + <target dev='vday' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1d' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data52'/> + <target dev='vdaz' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1e' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data53'/> + <target dev='vdba' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x01' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data54'/> + <target dev='vdbb' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x02' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data55'/> + <target dev='vdbc' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x03' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data56'/> + <target dev='vdbd' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x04' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data57'/> + <target dev='vdbe' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x05' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data58'/> + <target dev='vdbf' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x06' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data59'/> + <target dev='vdbg' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x07' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data60'/> + <target dev='vdbh' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x08' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data61'/> + <target dev='vdbi' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x09' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data62'/> + <target dev='vdbj' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x0a' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data63'/> + <target dev='vdbk' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x0b' +function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync' io='native' +discard='unmap'/> + <source file='/vms/tempp/vm-data1'/> + <target dev='vdbl' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' +function='0x0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='pci' index='1' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' +function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x1f' +function='0x0'/> + </controller> + </devices> + +> +> (3) migrate vm and vmâdisks +> +> +What do you mean by 'and vm disks' - are you doing a block migration? +> +Yes, block migration. +In fact, only migration domain also reproduced. + +> +Dave +> +> +> ---------------------------------------------------------------------- +> +> --------------------------------------------------------------- +> +Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK +------------------------------------------------------------------------------------------------------------------------------------- +æ¬é®ä»¶åå ¶é件å«ææ°åä¸éå¢çä¿å¯ä¿¡æ¯ï¼ä» éäºåéç»ä¸é¢å°åä¸ååº +ç个人æ群ç»ãç¦æ¢ä»»ä½å ¶ä»äººä»¥ä»»ä½å½¢å¼ä½¿ç¨ï¼å æ¬ä½ä¸éäºå ¨é¨æé¨åå°æ³é²ãå¤å¶ã +ææ£åï¼æ¬é®ä»¶ä¸çä¿¡æ¯ãå¦ææ¨éæ¶äºæ¬é®ä»¶ï¼è¯·æ¨ç«å³çµè¯æé®ä»¶éç¥å件人并å é¤æ¬ +é®ä»¶ï¼ +This e-mail and its attachments contain confidential information from New H3C, +which is +intended only for the person or entity whose address is listed above. Any use +of the +information contained herein in any way (including, but not limited to, total +or partial +disclosure, reproduction, or dissemination) by persons other than the intended +recipient(s) is prohibited. If you receive this e-mail in error, please notify +the sender +by phone or email immediately and delete it! + diff --git a/results/classifier/105/KVM/721659 b/results/classifier/105/KVM/721659 new file mode 100644 index 00000000..cc96a4e5 --- /dev/null +++ b/results/classifier/105/KVM/721659 @@ -0,0 +1,53 @@ +KVM: 0.875 +device: 0.833 +socket: 0.789 +mistranslation: 0.712 +graphic: 0.692 +semantic: 0.668 +instruction: 0.634 +other: 0.590 +network: 0.529 +assembly: 0.524 +boot: 0.471 +vnc: 0.434 + +qemu-kvm-0.13.0 doesn't pass USB devices to the VM + +I have the bug, similar to this one: +https://bugzilla.redhat.com/show_bug.cgi?id=583108 +but under gentoo + +When I add parameters -usb -usbdevice host:4348:5584, I see the following lines in console: + +husb: config #1 need -1 +USBDEVFS_DISCONNECT: No route to host +husb: open device 2.11 +(...many repetitions of three above lines...) + +All parameters (2.11) are verified with lsusb at host computer - parameters are correct + +Error description is very confusing - I don't know what to check, what "config #1" mean, which route should be checked and how to check it. + +Hi, + +Thanks for reporting this problem. + +Can you tell me a bit more about your configuration? For example: +What are the guest and host operating systems? + +Is it always "need -1"? Do you ever see "need 1"? + +What is the device you're trying to open? Can you show the USB descriptors (e.g. from lsusb)? + +Do you have rights to open the device (e.g. are you running qemu with elevated privileges)? Does it help / change things if you do or don't? + +I'm not sure that the error messages are very accurate in this particular case. I think the problem with those messages comes from use of perror() in the QEMU code and that the underlying operations aren't returning / setting errno in the right way (or perhaps at all). However the fact that we're even getting to the error path indicates a problem. If I had to guess, the device is already bound to a driver on the host and you don't have permissions to unbind it. However I'm pretty fuzzy on this one, and I'm really hoping the additional information might help someone else fix it. + +Brad + + + + + +QEMU 0.13.0 is quite outdated - and I assume that USB passthrough should be working fine with the latest version, so I'm closing this bug ticket now. If you still have problems with the latest version of QEMU, feel free to open it again (or create a new bug ticket instead). + diff --git a/results/classifier/105/KVM/73 b/results/classifier/105/KVM/73 new file mode 100644 index 00000000..80a6780b --- /dev/null +++ b/results/classifier/105/KVM/73 @@ -0,0 +1,14 @@ +KVM: 0.971 +device: 0.860 +other: 0.486 +boot: 0.392 +graphic: 0.365 +mistranslation: 0.268 +instruction: 0.265 +semantic: 0.250 +vnc: 0.147 +network: 0.145 +socket: 0.087 +assembly: 0.006 + +KVM Windows 98 sound card passthrough is not working for DOS programs.. diff --git a/results/classifier/105/KVM/735 b/results/classifier/105/KVM/735 new file mode 100644 index 00000000..d52876e3 --- /dev/null +++ b/results/classifier/105/KVM/735 @@ -0,0 +1,39 @@ +KVM: 0.962 +mistranslation: 0.953 +graphic: 0.944 +instruction: 0.780 +device: 0.737 +vnc: 0.631 +semantic: 0.495 +network: 0.489 +socket: 0.483 +boot: 0.329 +assembly: 0.250 +other: 0.238 + +softmmu 'at' not behaving +Description of problem: +This looks like a bug to me, please correct if I'm wrong. The execution context is EL2 here and we run KVM vms on top of the system emulation. Anyway, here we have stopped in the EL2 and want to translate a virtual address '0' with 'at'. While the '0' itself is not mapped, something in the first gigabyte is, and the softmmu refuses to walk to it: + +0x0000000100004a3c <at_s12e1r+8>: 80 78 0c d5 at s12e1r, x0 +0x0000000100004a40 <at_s12e1r+12>: 01 74 38 d5 mrs x1, par_el1 + +(gdb) info registers x0 x1 +x0 0x0 0 +x1 0x809 2057 + +So that would be translation fault level 0, stage 1 if I'm not mistaken. + +(gdb) info all-registers TCR_EL1 VTCR_EL2 TTBR1_EL1 +TCR_EL1 0x400035b5503510 18014629184681232 +VTCR_EL2 0x623590 6436240 +TTBR1_EL1 0x304000041731001 217298683118686209 + +(gdb) p print_table(0x41731000) +000:0x000000ffff9803 256:0x000000fffff803 507:0x00000041fbc803 +508:0x000000ff9ef803 + +The first gigabyte is populated, yet the 'at' knows nothing about it. Did I miss something? This seems to be working fine on the hardware. +Steps to reproduce: +1. Stop in the EL2 while the linux is running (GDB) +2. Use something along the lines of this function to translate any kernel virtual address: https://github.com/jkrh/kvms/blob/4c26c786be9971613b3b7f56121c1a1aa3b9585a/core/helpers.h#L74 diff --git a/results/classifier/105/KVM/735752 b/results/classifier/105/KVM/735752 new file mode 100644 index 00000000..79f81118 --- /dev/null +++ b/results/classifier/105/KVM/735752 @@ -0,0 +1,224 @@ +KVM: 0.151 +vnc: 0.139 +mistranslation: 0.131 +other: 0.076 +assembly: 0.070 +instruction: 0.062 +graphic: 0.053 +socket: 0.052 +network: 0.051 +semantic: 0.051 +device: 0.049 +boot: 0.044 + +qemu squeeze crashes "BUG: unable to handle kernel NULL pointer dereference at (null)" + +my virtual machine server (qemu+libvirt) regularly breaks down with such a record in the logs +I can not even ping the guest, but i can ping host, but can not do something with it (cannot ssh login for example) +And I dont know how to reproduce the problem :( + +Mar 15 17:58:04 mainhost kernel: [65866.976982] BUG: unable to handle kernel NULL pointer dereference at (null) +Mar 15 17:58:04 mainhost kernel: [65866.977422] IP: [<ffffffff8100efbe>] 0xffffffff8100efbe +Mar 15 17:58:04 mainhost kernel: [65866.977663] PGD 7387b7067 PUD 81b723067 PMD 0. +Mar 15 17:58:04 mainhost kernel: [65866.977902] Oops: 0000 [#1] SMP. +Mar 15 17:58:04 mainhost kernel: [65866.978128] last sysfs file: /sys/devices/system/cpu/cpu3/topology/thread_siblings +Mar 15 17:58:04 mainhost kernel: [65866.978572] CPU 1. +Mar 15 17:58:04 mainhost kernel: [65866.978577] Modules linked in: nfs lockd nfs_acl auth_rpcgss sunrpc ebtable_nat ebtables coretemp bridge stp llc xt_state +Mar 15 17:58:04 mainhost kernel: [65866.979737]. +Mar 15 17:58:04 mainhost kernel: [65866.979959] Pid: 3369, comm: qemu-system-x86 Not tainted 2.6.37-gentoo-r2 #2 Intel S5000VSA/S5000VSA +Mar 15 17:58:04 mainhost kernel: [65866.980085] RIP: 0010:[<ffffffff8100efbe>] [<ffffffff8100efbe>] 0xffffffff8100efbe +Mar 15 17:58:04 mainhost kernel: [65866.980085] RSP: 0018:ffff880738767a48 EFLAGS: 00010246 +Mar 15 17:58:04 mainhost kernel: [65866.980085] RAX: 0000000000000000 RBX: fffffffffffff001 RCX: ffff88081cbeb948 +Mar 15 17:58:04 mainhost kernel: [65866.980085] RDX: 0000000000000022 RSI: fffffffffffff001 RDI: ffff88081cbeb000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] RBP: 0000000000000001 R08: 00000000000fee01 R09: 0000000000000022 +Mar 15 17:58:04 mainhost kernel: [65866.980085] R10: 0000008000000000 R11: ffffea0000000000 R12: ffff880818d83490 +Mar 15 17:58:04 mainhost kernel: [65866.980085] R13: 00000000155e5000 R14: 0000000000000000 R15: 0000000000000100 +Mar 15 17:58:04 mainhost kernel: [65866.980085] FS: 00007f5f25e4e700(0000) GS:ffff88009f680000(0000) knlGS:fffff80001175000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +Mar 15 17:58:04 mainhost kernel: [65866.980085] CR2: 0000000000000000 CR3: 0000000806be9000 CR4: 00000000000426e0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] DR0: 0000000000000045 DR1: 0000000000000000 DR2: 0000000000000000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] DR3: 0000000000000005 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Mar 15 17:58:04 mainhost kernel: [65866.980085] Process qemu-system-x86 (pid: 3369, threadinfo ffff880738766000, task ffff8808203ac360) +Mar 15 17:58:04 mainhost kernel: [65866.980085] Stack: +Mar 15 17:58:04 mainhost kernel: [65866.980085] 0000000000000000 ffff8806a30f3ff8 ffff880753980000 ffffffff8100f06f +Mar 15 17:58:04 mainhost kernel: [65866.980085] 0000000000000ff8 ffff8807705d6b40 0000000000000ff8 ffffffff810123f0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +Mar 15 17:58:04 mainhost kernel: [65866.980085] Call Trace: +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f06f>] ? 0xffffffff8100f06f +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810123f0>] ? 0xffffffff810123f0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f744>] ? 0xffffffff8100f744 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100ffaf>] ? 0xffffffff8100ffaf +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810011f1>] ? 0xffffffff810011f1 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810142fc>] ? 0xffffffff810142fc +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100834d>] ? 0xffffffff8100834d +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff81011af6>] ? 0xffffffff81011af6 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100c5a7>] ? 0xffffffff8100c5a7 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff81003a85>] ? 0xffffffff81003a85 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810e19b0>] ? 0xffffffff810e19b0 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff81078cd8>] ? 0xffffffff81078cd8 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810e1a39>] ? 0xffffffff810e1a39 +Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810267fb>] ? 0xffffffff810267fb +Mar 15 17:58:04 mainhost kernel: [65866.980085] Code: 8b 47 50 8d 50 01 85 c0 89 57 50 75 07 41 58 e9 32 ff ff ff 5f c3 55 89 d5 53 48 89 f3 48 83 ec 08 e8 d +Mar 15 17:58:04 mainhost kernel: [65866.980085] RIP [<ffffffff8100efbe>] 0xffffffff8100efbe +Mar 15 17:58:04 mainhost kernel: [65866.980085] RSP <ffff880738767a48> +Mar 15 17:58:04 mainhost kernel: [65866.980085] CR2: 0000000000000000 +Mar 15 17:58:04 mainhost kernel: [65866.990753] ---[ end trace d147f74976c2654d ]--- + +Linux mainhost 2.6.37-gentoo-r2 #2 SMP Mon Mar 14 22:53:20 MSK 2011 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux + +app-emulation/qemu-kvm-0.13.0-r2 +app-emulation/libvirt-0.8.8-r1 + +mainhost log # ps ax|grep qemu + 2957 ? Sl 12:28 /usr/bin/qemu-system-x86_64 --enable-kvm -S -M pc-0.13 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name dc1 -uuid f090bfc9-1cab-e4e9-51ea-80c9cc775bff -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/dc1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -boot order=c,menu=off -drive file=/dev/vm-storage/dc1,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=13,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:a1:a7,bus=pci.0,addr=0x4 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:0,password -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 + 2982 ? Rl 10:34 /usr/bin/qemu-system-x86_64 --enable-kvm -S -M pc-0.13 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name transarchive -uuid b96a3481-1ad6-9329-387e-a1504a17d0ee -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/transarchive.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -boot order=c,menu=off -drive file=/dev/vm-storage/transarchive,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=13,id=hostnet0,vhost=on,vhostfd=17 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a9:f8:06,bus=pci.0,addr=0x3 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:3,password -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 + +On Tue, Mar 15, 2011 at 9:28 PM, Aidar Kamalov +<email address hidden> wrote: +> Mar 15 17:58:04 mainhost kernel: [65866.980085] Call Trace: +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f06f>] ? 0xffffffff8100f06f +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff810123f0>] ? 0xffffffff810123f0 +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100f744>] ? 0xffffffff8100f744 +> Mar 15 17:58:04 mainhost kernel: [65866.980085] [<ffffffff8100ffaf>] ? 0xffffffff8100ffaf + +Please compile a kernel with debug information so that the call trace +has function names. The option is CONFIG_DEBUG_INFO and can be +reached via "Kernel hacking | Compile the kernel with debug info" in +make menuconfig. + +Stefan + + +I have compiled with CONFIG_DEBUG_INFO, but core is not creating, i think i do all right: + +mainhost log # zcat /proc/config.gz |grep CONFIG_DEBUG_INFO +CONFIG_DEBUG_INFO=y +# CONFIG_DEBUG_INFO_REDUCED is not set + +mainhost log # cat /etc/security/limits.conf | grep core +# - core - limits the core file size (KB) +* soft core unlimited +mainhost log # ulimit -S -s +8192 +mainhost log # ulimit -H -s +unlimited +mainhost log # ulimit -S -s 100000 +mainhost log # ulimit -S -s +100000 +mainhost log # cat /proc/sys/kernel/core_pattern +core +mainhost log # cat /proc/sys/kernel/core_uses_pid +0 +mainhost log # ulimit -c +unlimited +mainhost log # yes & kill -ABRT `jobs -p` +[1] 3527 +mainhost log # +[1]+ Aborted (core dumped) yes + + +On Wed, Mar 16, 2011 at 8:27 PM, Aidar Kamalov +<email address hidden> wrote: +> I have compiled with CONFIG_DEBUG_INFO, but core is not creating, i +> think i do all right: +> +> mainhost log # zcat /proc/config.gz |grep CONFIG_DEBUG_INFO +> CONFIG_DEBUG_INFO=y +> # CONFIG_DEBUG_INFO_REDUCED is not set + +This looks fine + +> mainhost log # cat /etc/security/limits.conf | grep core +> # - core - limits the core file size (KB) +> * soft core unlimited +> mainhost log # ulimit -S -s +> 8192 +> mainhost log # ulimit -H -s +> unlimited +> mainhost log # ulimit -S -s 100000 +> mainhost log # ulimit -S -s +> 100000 +> mainhost log # cat /proc/sys/kernel/core_pattern +> core +> mainhost log # cat /proc/sys/kernel/core_uses_pid +> 0 +> mainhost log # ulimit -c +> unlimited +> mainhost log # yes & kill -ABRT `jobs -p` +> [1] 3527 +> mainhost log # +> [1]+ Aborted (core dumped) yes + +These are core dump options for userspace processes. You originally +posted a kernel backtrace and that is not affected by core dump +options. + +When the issue is triggered again you should see function names in the +"Call Trace:" section of the BUG output. + +Stefan + + +Issue is trigered, but there are nothing changes, i will try to get core + +Mar 16 21:50:29 mainhost kernel: [28123.087654] BUG: unable to handle kernel NULL pointer dereference at (null) +Mar 16 21:50:29 mainhost kernel: [28123.088106] IP: [<ffffffff8100fe7d>] 0xffffffff8100fe7d +Mar 16 21:50:29 mainhost kernel: [28123.088331] PGD 81a4f5067 PUD 81d08b067 PMD 0. +Mar 16 21:50:29 mainhost kernel: [28123.088555] Oops: 0000 [#1] SMP. +Mar 16 21:50:29 mainhost kernel: [28123.088776] last sysfs file: /sys/devices/system/cpu/cpu3/topology/thread_siblings +Mar 16 21:50:29 mainhost kernel: [28123.089218] CPU 2. +Mar 16 21:50:29 mainhost kernel: [28123.089223] Modules linked in: i5k_amb coretemp nfs lockd nfs_acl auth_rpcgss sunrpc ebtable_nat ebtables bridge stp llc +Mar 16 21:50:29 mainhost kernel: [28123.090526]. +Mar 16 21:50:29 mainhost kernel: [28123.090526] Pid: 2900, comm: qemu-system-x86 Not tainted 2.6.38-gentoo #2 Intel S5000VSA/S5000VSA +Mar 16 21:50:29 mainhost kernel: [28123.090526] RIP: 0010:[<ffffffff8100fe7d>] [<ffffffff8100fe7d>] 0xffffffff8100fe7d +Mar 16 21:50:29 mainhost kernel: [28123.090526] RSP: 0018:ffff88081b9b5a68 EFLAGS: 00010246 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RAX: 0000000000000000 RBX: fffffffffffff001 RCX: 00000000000fee01 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RDX: 0000000000000022 RSI: fffffffffffff001 RDI: ffff8807be235000 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RBP: 0000000000000001 R08: 0000000000000022 R09: 0000000000000040 +Mar 16 21:50:29 mainhost kernel: [28123.090526] R10: ffff88081b9b5be8 R11: 0000000000000000 R12: 0000000000000ff8 +Mar 16 21:50:29 mainhost kernel: [28123.090526] R13: 0000000001cbf000 R14: 0000000000000013 R15: 0000000000000000 +Mar 16 21:50:29 mainhost kernel: [28123.090526] FS: 00007fd821b70700(0000) GS:ffff88009f700000(0000) knlGS:000007fffffdd000 +Mar 16 21:50:29 mainhost kernel: [28123.090526] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +Mar 16 21:50:29 mainhost kernel: [28123.090526] CR2: 0000000000000000 CR3: 000000081d245000 CR4: 00000000000426e0 +Mar 16 21:50:29 mainhost kernel: [28123.090526] DR0: 0000000000000001 DR1: 0000000000000002 DR2: 0000000000000001 +Mar 16 21:50:29 mainhost kernel: [28123.090526] DR3: 000000000000000a DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Mar 16 21:50:29 mainhost kernel: [28123.090526] Process qemu-system-x86 (pid: 2900, threadinfo ffff88081b9b4000, task ffff88081f344fa0) +Mar 16 21:50:29 mainhost kernel: [28123.090526] Stack: +Mar 16 21:50:29 mainhost kernel: [28123.090526] 8000000815be5207 ffff8806bcf93ff8 ffff88081b9d4000 ffffffff8100ff2e +Mar 16 21:50:29 mainhost kernel: [28123.090526] ffffffff8100132a ffff88074b61a460 ffff88081a508000 ffffffff8101016c +Mar 16 21:50:29 mainhost kernel: [28123.090526] 0000000001cbf000 ffffffff81014d6d 000fffff00000001 0000000000001e76 +Mar 16 21:50:29 mainhost kernel: [28123.090526] Call Trace: +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8100ff2e>] ? 0xffffffff8100ff2e +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8100132a>] ? 0xffffffff8100132a +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8101016c>] ? 0xffffffff8101016c +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81014d6d>] ? 0xffffffff81014d6d +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810106a9>] ? 0xffffffff810106a9 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810147d0>] ? 0xffffffff810147d0 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81014c94>] ? 0xffffffff81014c94 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8102283d>] ? 0xffffffff8102283d +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810262a1>] ? 0xffffffff810262a1 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff8100d1b6>] ? 0xffffffff8100d1b6 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81003f86>] ? 0xffffffff81003f86 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810e0b37>] ? 0xffffffff810e0b37 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff81341d8e>] ? 0xffffffff81341d8e +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810ed54c>] ? 0xffffffff810ed54c +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810ed5d5>] ? 0xffffffff810ed5d5 +Mar 16 21:50:29 mainhost kernel: [28123.090526] [<ffffffff810287fb>] ? 0xffffffff810287fb +Mar 16 21:50:29 mainhost kernel: [28123.090526] Code: 8b 47 50 8d 50 01 85 c0 89 57 50 75 07 41 58 e9 32 ff ff ff 5e c3 55 89 d5 53 48 89 f3 48 83 ec 08 e8 9 +Mar 16 21:50:29 mainhost kernel: [28123.090526] RIP [<ffffffff8100fe7d>] 0xffffffff8100fe7d +Mar 16 21:50:29 mainhost kernel: [28123.090526] RSP <ffff88081b9b5a68> +Mar 16 21:50:29 mainhost kernel: [28123.090526] CR2: 0000000000000000 +Mar 16 21:50:29 mainhost kernel: [28123.102127] ---[ end trace 68b482cf7220ceeb ]--- + + +well, i has downgraded to 2.6.33 and system stable for 3 days yet.. +system is halted on 2.6.36, 2,6.37 and 2.6.38 kernels + +mainhost ~ # uptime + 12:38:30 up 3 days, 2:56, 2 users, load average: 0.00, 0.00, 0.04 +mainhost ~ # uname -a +Linux mainhost 2.6.33-gentoo-r1 #4 SMP Tue Aug 24 09:53:21 MSD 2010 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux + + +Sounds like this was a kernel bug ... you should report those to the right kernel mailing lists instead. Anyway, closing this ticket now since there hasn't been any activity since a long time. + diff --git a/results/classifier/105/KVM/747583 b/results/classifier/105/KVM/747583 new file mode 100644 index 00000000..e7236aa1 --- /dev/null +++ b/results/classifier/105/KVM/747583 @@ -0,0 +1,40 @@ +KVM: 0.726 +device: 0.628 +mistranslation: 0.615 +instruction: 0.608 +graphic: 0.494 +network: 0.490 +semantic: 0.468 +other: 0.451 +assembly: 0.294 +socket: 0.271 +vnc: 0.259 +boot: 0.161 + +Windows 2008 Time Zone Change Even When Using -locatime + +* What cpu model : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz +* What kvm version you are using. : qemu-kvm-0.12.3 +* The host kernel version : 2.6.32-30-server +* What host kernel arch you are using (i386 or x86_64) : x86_64 +* What guest you are using, including OS type: Windows 2008 Enterprise x86_64 +* The qemu command line you are using to start the guest : /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 1024 -smp 1 -name 2-6176 -uuid 4d1d56b1-d0b7-506b-31a5-a87c8cb0560b -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/2-6176.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/dev/disk/by-id/scsi-3600144f05c11090000004d9602950073,if=virtio,index=0,boot=on,format=raw -drive file=/dev/disk/by-id/scsi-3600144f0eae8810000004c7bb0920037,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:00:d1:d0:3f:5e,vlan=0,name=nic.1 -net tap,fd=212,vlan=0,name=tap.1 -net nic,macaddr=00:00:0a:d0:3f:5e,vlan=1,name=nic.1 -net tap,fd=213,vlan=1,name=tap.1 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 0.0.0.0:394,password -k en-us -vga cirrus +* Whether the problem goes away if using the -no-kvm-irqchip or -no-kvm-pit switch. : Unable to test +* Whether the problem also appears with the -no-kvm switch. : Unable to test + +Host time zone: EDT Guest time zone: PDT + +Steps to reproduce: +1) Set time zone to (GMT-08:00) Pacific Time (US & Canada) on guest +2) Power off Windows 2008 Enterprise x86_64 guest completely. Ensure the kvm process exits. +3) Power on Windows 2008 Enterprise x86_64 guest using virsh start <domain> +4) Server will show EDT time but have the time zone still set to (GMT-08:00) Pacific Time (US & Canada). + +Syncing the time after stopping and starting the kvm process using Windows "Internet Time" ntp time sync will sync the time to the correct PDT time. + +Doing a reboot from within the guest's operating system where kvm does not exit will not cause the timezone shift to happen. + +QEMU 0.12 is completely outdated nowadays ... can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/748 b/results/classifier/105/KVM/748 new file mode 100644 index 00000000..390abbde --- /dev/null +++ b/results/classifier/105/KVM/748 @@ -0,0 +1,14 @@ +KVM: 0.888 +device: 0.807 +network: 0.763 +vnc: 0.526 +instruction: 0.492 +boot: 0.480 +graphic: 0.437 +socket: 0.403 +other: 0.380 +semantic: 0.327 +assembly: 0.119 +mistranslation: 0.076 + +Enable postcopy migration for mixed Hugepage backed KVM guests and improve handling of dirty-page tracking by QEMU/KVM diff --git a/results/classifier/105/KVM/772275 b/results/classifier/105/KVM/772275 new file mode 100644 index 00000000..6ef5f4d5 --- /dev/null +++ b/results/classifier/105/KVM/772275 @@ -0,0 +1,57 @@ +KVM: 0.520 +other: 0.502 +vnc: 0.495 +boot: 0.427 +device: 0.373 +mistranslation: 0.342 +network: 0.315 +instruction: 0.308 +graphic: 0.301 +socket: 0.284 +semantic: 0.281 +assembly: 0.270 + +qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging + +Hi, + +I'm a proxmox distrib user, + +I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. + +after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. + +e1000 driver working fine. + +revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. + +i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + +i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 + +i'm not the only proxmox user ,more users reports here : + +http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-drivers-for-Windows-and-latest-PVE-1.8 + +i've also see that a slackware user with winxp guest has the same problem + +http://www.spinics.net/lists/kvm/msg51089.html + + +I can help to debug if it's possible to have logs somewhere ..... + +Forget to say: + +i'm using a quad-amd opteron 6172 (12cores) server, 256gb ram. + +kvm guest launch command: + +/usr/bin/kvm -monitor unix:/var/run/qemu-server/124.mon,server,nowait -vnc unix:/var/run/qemu-server/124.vnc,password -pidfile /var/run/qemu-server/124.pid -daemonize -usbdevice tablet -name testmachine -smp sockets=1,cores=12 -nodefaults -boot menu=on -tdf -localtime -rtc-td-hack -k fr -vga std -device lsi,id=scsi0,bus=pci.0,addr=0x5 -device lsi,id=scsi1,bus=pci.0,addr=0x6 -drive file=/dev/cdrom,if=none,id=drive-ide2,media=cdrom -device ide-drive,bus=ide.1,unit=0,drive=drive-ide2,id=disk-ide2 -drive file=/dev/disk/by-id/scsi-3600144f0f62f0e0000004d64fcaf000f,if=none,id=drive-virtio0,cache=none,boot=on -device virtio-blk-pci,drive=drive-virtio0,id=disk-virtio0,bus=pci.0,addr=0x7 -drive file=/dev/disk/by-id/scsi-3600144f0f62f0e0000004d6614f00012,if=none,id=drive-virtio1,cache=none -device virtio-blk-pci,drive=drive-virtio1,id=disk-virtio1,bus=pci.0,addr=0x8 -m 4000 -netdev type=tap,id=netdev2,ifname=tap124i101d2,script=/var/lib/qemu-server/bridge-vlan,vhost=on -device virtio-net-pci,mac=76:33:01:8E:91:B8,netdev=netdev2,id=nic2,bus=pci.0,addr=0x18 -netdev type=tap,id=netdev1,ifname=tap124i31d1,script=/var/lib/qemu-server/bridge-vlan,vhost=on -device virtio-net-pci,mac=02:A5:80:68:5E:EA,netdev=netdev1,id=nic1,bus=pci.0,addr=0x17 + + + + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU and the latest version of the virtio-net drivers? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/785668 b/results/classifier/105/KVM/785668 new file mode 100644 index 00000000..c1716f2b --- /dev/null +++ b/results/classifier/105/KVM/785668 @@ -0,0 +1,420 @@ +KVM: 0.892 +assembly: 0.850 +graphic: 0.811 +device: 0.791 +other: 0.789 +network: 0.774 +instruction: 0.765 +vnc: 0.719 +semantic: 0.692 +mistranslation: 0.687 +boot: 0.687 +socket: 0.649 + +bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM + +Binary package hint: qemu-kvm + +Description: Ubuntu 10.4.2 +Release: 10.04 + + +When setting a KVM host with a bond0 interface made of eth0 and eth1 and using this bond0 interface for a bridge to KVM VMs, the ARP tables do not get updated correctly and + +Reproducible: 100%, with any of the load balancing mode + +How to reproduce the problem + +- Prerequisites: +1 One KVM system with 10.04.02 server, configured as a virtual host is needed. The following /etc/network/interfaces was used for the test : + +# grep -v ^# /etc/network/interfaces +auto lo +iface lo inet loopback + + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode balance-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 + bridge-stp off + bridge-fd 9 + bridge-hello 2 + bridge-maxage 12 + bridge_max_wait 0 + +One VM running Maverick 10.10 server, standard installation, using the following /etc/network/interfaces file : + +grep -v ^# /etc/network/interfaces + +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet static + address 10.153.107.92 + netmask 255.255.255.0 + network 10.153.107.0 + broadcast 10.153.107.255 + +-------------- +On a remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +On VM +$ arp -an +? (10.153.107.61) at <incomplete> on eth0 + +1) Test #1 : ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : + +- On remote bridged network system : +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +From 10.153.107.92 icmp_seq=1 Destination Host Unreachable +From 10.153.107.92 icmp_seq=2 Destination Host Unreachable +From 10.153.107.92 icmp_seq=3 Destination Host Unreachable +^C +--- 10.153.107.80 ping statistics --- +4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3010ms +pipe 3 +ubuntu@vm1:~$ arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at <incomplete> on eth0 + +2) Test #2 : ping from remote bridged network system (10.153.107.80) to VM (10.153.107.92) : + +- On remote bridged network system : +$ ping 10.153.107.92 +PING 10.153.107.92 (10.153.107.92) 56(84) bytes of data. +64 bytes from 10.153.107.92: icmp_req=1 ttl=64 time=327 ms +64 bytes from 10.153.107.92: icmp_req=2 ttl=64 time=158 ms +64 bytes from 10.153.107.92: icmp_req=3 ttl=64 time=157 ms +^C +--- 10.153.107.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 157.289/214.500/327.396/79.831 ms +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on eth0 + + +3) Test #3 : New ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : +- On remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +64 bytes from 10.153.107.80: icmp_req=1 ttl=64 time=154 ms +64 bytes from 10.153.107.80: icmp_req=2 ttl=64 time=170 ms +64 bytes from 10.153.107.80: icmp_req=3 ttl=64 time=154 ms +^C +--- 10.153.107.80 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 154.072/159.465/170.058/7.504 ms + +tcpdump traces are available for those tests. Test system is available upon request. + +Workaround: + +Use the bonded device in "active-backup" mode + +ProblemType: Bug +DistroRelease: Ubuntu 10.04.02 +Package: qemu-kvm-0.12.3+noroms-0ubuntu9.6 +Uname: Linux 2.6.35-25-serverr x86_64 +Architecture: amd64 + +Thanks for reporting this bug and the detailed reproduction instructions. I would mark it high, but since you offer a workaround I'll mark it medium instead. + +What does your /etc/modprobe.d/bonding show? + +I've not used this combination myself, but from those who have, a few things do appear fragile, namely: + +1. if you are using 802.3ad, you need trunking enabled on the physical switch + +2. some people find that turning stp on helps (http://www.linuxquestions.org/questions/linux-networking-3/bridging-a-bond-802-3ad-only-works-when-stp-is-enabled-741640/) + +But I'm actually wondering whether this patch: + +http://permalink.gmane.org/gmane.linux.network/159403 + +may be needed. If so, then even the natty kernel does not yet have that fix. + +I am marking this as affecting the kernel, since I believe that is where the bug lies. + + +Actually, I may be wrong about this being a kernel issue. + +Are you always able to ping the remote host from the kvm host, even when you can't do so from the VM? + +In addition to kvmhost's /etc/modprove.d/bonding.conf, can you also please provide the configuration info for the KVM vm? (If a libvirt host, then the network-related (or just all) xml info, or else the 'ps -ef | grep kvm' output). Also the network configuration insid the KVM VM. In particular, if the KVM VM has a bridge, that one would need to have stp turned on, but I doubt you have that. + +Yup, I can reproduce this 100%. + +I'm setting up networking as described above, and then starting virtual machines with: + +sudo tunctl -u 1000 -g 1000 -t tap0 +sudo /sbin/ifconfig $1 0.0.0.0 up +sudo brctl addif br0 tap0 + +kvm -drive file=disk.img,if=virtio,cache=none,boot=on -m 1024 -vnc :1 -net nic,model=virtio -net tap,script=no,ifname=tap0,downscript=no + +With mode=balance-rr, I can't run dhclient from the guest. With either +bond0 as active-backup, or without bond0 (with eth0 directly in br0), +I can. + + +Following the advice toward the bottom of + +http://forum.proxmox.com/archive/index.php/t-2676.html?s=e8a9cfc9a128659e4a61efec0b758d3e + +I was able to get this to work with balance-rr by changing a few bridge properties. The following was my /etc/network/interfaces: + +# This file describes the network interfaces available on your system +# and how to activate them. For more information, see interfaces(5). + +# The loopback network interface +auto lo +iface lo inet loopback + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode active-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 +# bridge-stp off +# bridge-fd 9 +# bridge-hello 2 +# bridge-maxage 12 +# bridge_max_wait 0 + bridge_stp on + bridge_maxwait 0 + bridge_maxage 0 + bridge_fd 0 + bridge_ageing 0 + +I don't know if this is acceptable to you since stp is on. If not, is using balance-alb (which did also work for me) acceptable? + +Following your suggestions, I modified my /etc/network/interfaces & added the STP options to my test environment. Following that, I am now able to ping to the remote system using the following bonding modes : + +* 802.3ad (4) +* tlb (5) +* alb (6) + +For unknown reasons, I'm still unable to use balance-rr unlike your setup. But that might not be much of an issue as those modes listed above might be sufficient. I must go & check that. And now, the two VMs are able to ping each other. + +One thing regarding your listed /etc/network/interfaces : I think that there is a typo as 'bond_mode active-rr' is not a support bonding mode. + +Regarding your request for /etc/modprove.d/bonding.conf, there is no such file on my test system. Let me know if you still require the xml dump of the VM. + +Quoting Louis Bouchard (<email address hidden>): +> Regarding your request for /etc/modprove.d/bonding.conf, there is no +> such file on my test system. + +Right, sorry, that's obsolete as of hardy, sorry. + +> Let me know if you still require the xml +> dump of the VM. + +Thanks, no, as I'm able to reproduce that won't be necessary. + + +I can reproduce this just using lxc, which simply attaches an endpoint of a veth tunnel to the bridge. With balance-rr mode, i can't dhcp in the guest. With balance-alb, I can. + +That means this is not actually qemu-kvm, but a bug in the kernel or (unlikely) ifenslave. + +My next steps will be to test on maverick and natty, look through linux-2.6/drivers/net/bonding and linux-2.6/net/bridge/ and perhaps go to the https://lists.linux-foundation.org/pipermail/bridge/2011-May/thread.html list to ask for help if it is still broken in natty. + +Maverick gives me the same result. (Except I don't seem able, in maverick, to auto-setup the bond+bridge setup with /etc/network/interfaces, keep having to do it by hand. Hoping I did something wrong myself,a nd it's not a maverick bug) + +Natty is still affected. + +Since qemu isn't needed to show the bug, you can now trivially test this inside a natty kvm container by giving it two NICs, setting up /etc/network interfaces as shown above, and using lxc as follows: + + apt-get install lxc debootstrap + mkdir /cgroup + mount -t cgroup cgroup /cgroup + cat > /etc/lxc.conf << EOF + lxc.network.type=veth + lxc.network.link=br0 + lxc.network.flags=up + EOF + lxc-create -t natty -n lxc -f /etc/lxc.conf + lxc-start -n lxc + +When not using balance-rr, the container's network is fine. When using balance-rr, it can't get a dhcp address. + +Next step is probably to look at the hwaddr handling in the kernel source, and talk to upstream. + + +I sent an email to bonding-devel, and got this response: + +http://sourceforge.net/mailarchive/forum.php?thread_name=21866.1306527811%40death&forum_name=bonding-devel + +Assuming that your switch is in fact set up for Etherchannel, can you go ahead and gather the tcpdump data? + +I read the mail and did a first round of test before I could check the setting of the switch. Here are the transcript of the test with balance-rr. + +Container : LXC container with fixed IP +VMhost : The host where the LXC container runs. configured with br0 & bond0 +remote_host : another host on the same bridged subnet + +Container : date;ping xxx.xxx.xxx.87 +Mon May 30 15:40:49 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +^C--- xxx.xxx.xxx.87 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss + + +VMhost : date;ping xxx.xxx.xxx.92 +Mon May 30 15:41:14 EDT 2011 +PING xxx.xxx.xxx.92 (xxx.xxx.xxx.92) 56(84) bytes of data. +64 bytes from xxx.xxx.xxx.92: icmp_req=9 ttl=64 time=10.1 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=10 ttl=64 time=0.087 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=11 ttl=64 time=0.076 ms +^C +--- xxx.xxx.xxx.92 ping statistics --- +11 packets transmitted, 3 received, 72% packet loss, time 10004ms +rtt min/avg/max/mdev = 0.076/3.423/10.108/4.727 ms + + +Container : date;ping xxx.xxx.xxx.87 +Mon May 30 15:41:41 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +^C--- xxx.xxx.xxx.87 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss + + +remote_host : date;ping xxx.xxx.xxx.92 +lundi 30 mai 2011, 15:42:03 (UTC+0200) +PING xxx.xxx.xxx.92 (xxx.xxx.xxx.92) 56(84) bytes of data. +64 bytes from xxx.xxx.xxx.92: icmp_req=1 ttl=64 time=284 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=2 ttl=64 time=125 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=3 ttl=64 time=134 ms +^C +--- xxx.xxx.xxx.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2002ms +rtt min/avg/max/mdev = 125.282/181.561/284.952/73.204 ms + + +Container : Mon May 30 15:42:24 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +56 bytes from xxx.xxx.xxx.87: icmp_seq=0 ttl=64 time=141.506 ms +56 bytes from xxx.xxx.xxx.87: icmp_seq=1 ttl=64 time=153.311 ms +56 bytes from xxx.xxx.xxx.87: icmp_seq=2 ttl=64 time=124.973 ms +^C--- xxx.xxx.xxx.87 ping statistics --- +3 packets transmitted, 3 packets received, 0% packet loss +round-trip min/avg/max/stddev = 124.973/139.930/153.311/11.622 ms + +I will send you the dump data directly. Now that I have full access to our switch, I will do more tests tomorrow. As far as I know, the switch is doing automatic trunking so the switch should not be an issue. + + +Hello, + +Now I am dazed and confused (and trying to continue) + +I have tested most of the combination of bonding modes with appropriate switch settings and here is what I get : + +Bonding mode switch configuration result(ping from Container) With STP +============ ==================== ====== ======== +balance-rr two port trunked OK +balance-rr No trunking NOK OK +balance-alb No trunking OK +balance-tlb No trunking OK +802.3ad LACP dynamic trunk OK +balance-xor two port trunked OK +balance-xor No trunking NOK NOK + +I could swear that I had tested -alb and -tlb with negative results. So apparently, the STP workaround is not required with proper switch configuration. + +It looks like this has been fixed upstream. I will close it. If the problem still occurs, please reopen it. + + diff --git a/results/classifier/105/KVM/797905 b/results/classifier/105/KVM/797905 new file mode 100644 index 00000000..25f8dc55 --- /dev/null +++ b/results/classifier/105/KVM/797905 @@ -0,0 +1,65 @@ +KVM: 0.990 +instruction: 0.969 +other: 0.962 +mistranslation: 0.962 +assembly: 0.924 +semantic: 0.913 +device: 0.909 +graphic: 0.889 +network: 0.874 +vnc: 0.818 +socket: 0.767 +boot: 0.710 + +virsh live migration + +Hi, +i do not manage to do a virsh migrate live command. +Using Ubuntu Server 10.04 x64 + +root@svr50abl:~# virsh list + Id Nome Estado +---------------------------------- + 18 Winxp executando + 19 teste executando + +root@svr50abl:~# sudo virsh migrate --live 19 qemu+ssh://10.1.5.1/system +root@10.1.5.1's password: +erro: unable to set user and group to '116:127' on '/var/lib/libvirt/images/teste.img': No such file or directory + +teste.img has root:root (xrw) + +10.1.5.1 is a functional kvm host too + +On Wed, Jun 15, 2011 at 9:35 PM, Marcus Paiva <email address hidden> wrote: +> Public bug reported: +> +> Hi, +> i do not manage to do a virsh migrate live command. +> Using Ubuntu Server 10.04 x64 +> +> root@svr50abl:~# virsh list +> Id Nome Estado +> ---------------------------------- +> 18 Winxp executando +> 19 teste executando +> +> root@svr50abl:~# sudo virsh migrate --live 19 qemu+ssh://10.1.5.1/system +> root@10.1.5.1's password: +> erro: unable to set user and group to '116:127' on '/var/lib/libvirt/images/teste.img': No such file or directory +> +> teste.img has root:root (xrw) + +The image file should be shared (for example over NFS) and visible on +both hosts. It looks like you are migrating to a host that does not +have /var/lib/libvirt/images/teste.img. + +Please check with libvirt, this is not a QEMU bug. + +Stefan + + +You can try to copy the image file from source to destination before migration. + +Closing, as this is a libvirt issue, not a QEMU bug. + diff --git a/results/classifier/105/KVM/80615920 b/results/classifier/105/KVM/80615920 new file mode 100644 index 00000000..b06a8931 --- /dev/null +++ b/results/classifier/105/KVM/80615920 @@ -0,0 +1,356 @@ +KVM: 0.803 +mistranslation: 0.800 +other: 0.786 +vnc: 0.768 +instruction: 0.751 +boot: 0.750 +device: 0.748 +assembly: 0.747 +semantic: 0.737 +network: 0.732 +socket: 0.732 +graphic: 0.730 + +[BUG] accel/tcg: cpu_exec_longjmp_cleanup: assertion failed: (cpu == current_cpu) + +It seems there is a bug in SIGALRM handling when 486 system emulates x86_64 +code. + +This code: + +#include <stdio.h> +#include <stdlib.h> +#include <pthread.h> +#include <signal.h> +#include <unistd.h> + +pthread_t thread1, thread2; + +// Signal handler for SIGALRM +void alarm_handler(int sig) { + // Do nothing, just wake up the other thread +} + +// Thread 1 function +void* thread1_func(void* arg) { + // Set up the signal handler for SIGALRM + signal(SIGALRM, alarm_handler); + + // Wait for 5 seconds + sleep(1); + + // Send SIGALRM signal to thread 2 + pthread_kill(thread2, SIGALRM); + + return NULL; +} + +// Thread 2 function +void* thread2_func(void* arg) { + // Wait for the SIGALRM signal + pause(); + + printf("Thread 2 woke up!\n"); + + return NULL; +} + +int main() { + // Create thread 1 + if (pthread_create(&thread1, NULL, thread1_func, NULL) != 0) { + fprintf(stderr, "Failed to create thread 1\n"); + return 1; + } + + // Create thread 2 + if (pthread_create(&thread2, NULL, thread2_func, NULL) != 0) { + fprintf(stderr, "Failed to create thread 2\n"); + return 1; + } + + // Wait for both threads to finish + pthread_join(thread1, NULL); + pthread_join(thread2, NULL); + + return 0; +} + + +Fails with this -strace log (there are also unsupported syscalls 334 and 435, +but it seems it doesn't affect the code much): + +... +736 rt_sigaction(SIGALRM,0x000000001123ec20,0x000000001123ecc0) = 0 +736 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 1,tv_nsec = 0},{tv_sec = +1,tv_nsec = 0}) +736 rt_sigprocmask(SIG_BLOCK,0x00000000109fad20,0x0000000010800b38,8) = 0 +736 Unknown syscall 435 +736 +clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID| + ... +736 rt_sigprocmask(SIG_SETMASK,0x0000000010800b38,NULL,8) +736 set_robust_list(0x11a419a0,0) = -1 errno=38 (Function not implemented) +736 rt_sigprocmask(SIG_SETMASK,0x0000000011a41fb0,NULL,8) = 0 + = 0 +736 pause(0,0,2,277186368,0,295966400) +736 +futex(0x000000001123f990,FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,738,NULL,NULL,0) + = 0 +736 rt_sigprocmask(SIG_BLOCK,0x00000000109fad20,0x000000001123ee88,8) = 0 +736 getpid() = 736 +736 tgkill(736,739,SIGALRM) = 0 + = -1 errno=4 (Interrupted system call) +--- SIGALRM {si_signo=SIGALRM, si_code=SI_TKILL, si_pid=736, si_uid=0} --- +0x48874a != 0x3c69e10 +736 rt_sigprocmask(SIG_SETMASK,0x000000001123ee88,NULL,8) = 0 +** +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +0x48874a != 0x3c69e10 +** +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +# + +The code fails either with or without -singlestep, the command line: + +/usr/bin/qemu-x86_64 -L /opt/x86_64 -strace -singlestep /opt/x86_64/alarm.bin + +Source code of QEMU 8.1.1 was modified with patch "[PATCH] qemu/timer: Don't +use RDTSC on i486" [1], +with added few ioctls (not relevant) and cpu_exec_longjmp_cleanup() now prints +current pointers of +cpu and current_cpu (line "0x48874a != 0x3c69e10"). + +config.log (built as a part of buildroot, basically the minimal possible +configuration for running x86_64 on 486): + +# Configured with: +'/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/build/qemu-8.1.1/configure' + '--prefix=/usr' +'--cross-prefix=/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/host/bin/i486-buildroot-linux-gnu-' + '--audio-drv-list=' +'--python=/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/host/bin/python3' + +'--ninja=/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/host/bin/ninja' +'--disable-alsa' '--disable-bpf' '--disable-brlapi' '--disable-bsd-user' +'--disable-cap-ng' '--disable-capstone' '--disable-containers' +'--disable-coreaudio' '--disable-curl' '--disable-curses' +'--disable-dbus-display' '--disable-docs' '--disable-dsound' '--disable-hvf' +'--disable-jack' '--disable-libiscsi' '--disable-linux-aio' +'--disable-linux-io-uring' '--disable-malloc-trim' '--disable-membarrier' +'--disable-mpath' '--disable-netmap' '--disable-opengl' '--disable-oss' +'--disable-pa' '--disable-rbd' '--disable-sanitizers' '--disable-selinux' +'--disable-sparse' '--disable-strip' '--disable-vde' '--disable-vhost-crypto' +'--disable-vhost-user-blk-server' '--disable-virtfs' '--disable-whpx' +'--disable-xen' '--disable-attr' '--disable-kvm' '--disable-vhost-net' +'--disable-download' '--disable-hexagon-idef-parser' '--disable-system' +'--enable-linux-user' '--target-list=x86_64-linux-user' '--disable-vhost-user' +'--disable-slirp' '--disable-sdl' '--disable-fdt' '--enable-trace-backends=nop' +'--disable-tools' '--disable-guest-agent' '--disable-fuse' +'--disable-fuse-lseek' '--disable-seccomp' '--disable-libssh' +'--disable-libusb' '--disable-vnc' '--disable-nettle' '--disable-numa' +'--disable-pipewire' '--disable-spice' '--disable-usb-redir' +'--disable-install-blobs' + +Emulation of the same x86_64 code with qemu 6.2.0 installed on another x86_64 +native machine works fine. + +[1] +https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg05387.html +Best regards, +Petr + +On Sat, 25 Nov 2023 at 13:09, Petr Cvek <petrcvekcz@gmail.com> wrote: +> +> +It seems there is a bug in SIGALRM handling when 486 system emulates x86_64 +> +code. +486 host is pretty well out of support currently. Can you reproduce +this on a less ancient host CPU type ? + +> +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +> +(cpu == current_cpu) +> +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +assertion failed: (cpu == current_cpu) +> +0x48874a != 0x3c69e10 +> +** +> +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +> +(cpu == current_cpu) +> +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +assertion failed: (cpu == current_cpu) +What compiler version do you build QEMU with? That +assert is there because we have seen some buggy compilers +in the past which don't correctly preserve the variable +value as the setjmp/longjmp spec requires them to. + +thanks +-- PMM + +Dne 27. 11. 23 v 10:37 Peter Maydell napsal(a): +> +On Sat, 25 Nov 2023 at 13:09, Petr Cvek <petrcvekcz@gmail.com> wrote: +> +> +> +> It seems there is a bug in SIGALRM handling when 486 system emulates x86_64 +> +> code. +> +> +486 host is pretty well out of support currently. Can you reproduce +> +this on a less ancient host CPU type ? +> +It seems it only fails when the code is compiled for i486. QEMU built with the +same compiler with -march=i586 and above runs on the same physical hardware +without a problem. All -march= variants were executed on ryzen 3600. + +> +> ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +> +> failed: (cpu == current_cpu) +> +> Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +> assertion failed: (cpu == current_cpu) +> +> 0x48874a != 0x3c69e10 +> +> ** +> +> ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +> +> failed: (cpu == current_cpu) +> +> Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +> assertion failed: (cpu == current_cpu) +> +> +What compiler version do you build QEMU with? That +> +assert is there because we have seen some buggy compilers +> +in the past which don't correctly preserve the variable +> +value as the setjmp/longjmp spec requires them to. +> +i486 and i586+ code variants were compiled with GCC 13.2.0 (more exactly, +slackware64 current multilib distribution). + +i486 binary which runs on the real 486 is also GCC 13.2.0 and installed as a +part of the buildroot crosscompiler (about two week old git snapshot). + +> +thanks +> +-- PMM +best regards, +Petr + +On 11/25/23 07:08, Petr Cvek wrote: +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +# + +The code fails either with or without -singlestep, the command line: + +/usr/bin/qemu-x86_64 -L /opt/x86_64 -strace -singlestep /opt/x86_64/alarm.bin + +Source code of QEMU 8.1.1 was modified with patch "[PATCH] qemu/timer: Don't use +RDTSC on i486" [1], +with added few ioctls (not relevant) and cpu_exec_longjmp_cleanup() now prints +current pointers of +cpu and current_cpu (line "0x48874a != 0x3c69e10"). +If you try this again with 8.2-rc2, you should not see an assertion failure. +You should see instead + +QEMU internal SIGILL {code=ILLOPC, addr=0x12345678} +which I think more accurately summarizes the situation of attempting RDTSC on hardware +that does not support it. +r~ + +Dne 29. 11. 23 v 15:25 Richard Henderson napsal(a): +> +On 11/25/23 07:08, Petr Cvek wrote: +> +> ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +> +> failed: (cpu == current_cpu) +> +> Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +> assertion failed: (cpu == current_cpu) +> +> # +> +> +> +> The code fails either with or without -singlestep, the command line: +> +> +> +> /usr/bin/qemu-x86_64 -L /opt/x86_64 -strace -singlestep +> +> /opt/x86_64/alarm.bin +> +> +> +> Source code of QEMU 8.1.1 was modified with patch "[PATCH] qemu/timer: Don't +> +> use RDTSC on i486" [1], +> +> with added few ioctls (not relevant) and cpu_exec_longjmp_cleanup() now +> +> prints current pointers of +> +> cpu and current_cpu (line "0x48874a != 0x3c69e10"). +> +> +> +If you try this again with 8.2-rc2, you should not see an assertion failure. +> +You should see instead +> +> +QEMU internal SIGILL {code=ILLOPC, addr=0x12345678} +> +> +which I think more accurately summarizes the situation of attempting RDTSC on +> +hardware that does not support it. +> +> +Compilation of vanilla qemu v8.2.0-rc2 with -march=i486 by GCC 13.2.0 and +running the resulting binary on ryzen still leads to: + +** +ERROR:../accel/tcg/cpu-exec.c:533:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:533:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +Aborted + +> +> +r~ +Petr + diff --git a/results/classifier/105/KVM/809 b/results/classifier/105/KVM/809 new file mode 100644 index 00000000..e393efd3 --- /dev/null +++ b/results/classifier/105/KVM/809 @@ -0,0 +1,14 @@ +KVM: 0.914 +mistranslation: 0.846 +device: 0.790 +instruction: 0.687 +graphic: 0.543 +semantic: 0.453 +network: 0.349 +assembly: 0.309 +boot: 0.100 +other: 0.081 +vnc: 0.028 +socket: 0.010 + +ppc cpu_interrupt_exittb kvm check is inverted diff --git a/results/classifier/105/KVM/810588 b/results/classifier/105/KVM/810588 new file mode 100644 index 00000000..3b65944f --- /dev/null +++ b/results/classifier/105/KVM/810588 @@ -0,0 +1,52 @@ +KVM: 0.551 +device: 0.547 +semantic: 0.531 +mistranslation: 0.511 +instruction: 0.483 +graphic: 0.473 +other: 0.442 +socket: 0.373 +boot: 0.338 +vnc: 0.337 +network: 0.304 +assembly: 0.225 + +Unexpected crash of qemu-kvm with SCSI disk emulation. + +Virual machine with MS windows 2003 installed on the virtual scsi disk (-drive file=/my/path/myimage.qcow2.img,boot=on,if=scsi,media=disk,bus=0,unit=1) unexpectedly crashes without core dump. When the image is connected as an ide disk (-hda ) vm flies normally. +Qemu-kvm version: 0.12.5 +Os/distr.: Debian squeeze, x86_64 + +On Thu, Jul 14, 2011 at 5:43 PM, Constantine Chernov +<email address hidden> wrote: +> Virual machine with MS windows 2003 installed on the virtual scsi disk (-drive file=/my/path/myimage.qcow2.img,boot=on,if=scsi,media=disk,bus=0,unit=1) unexpectedly crashes without core dump. When the image is connected as an ide disk (-hda ) vm flies normally. +> Qemu-kvm version: 0.12.5 +> Os/distr.: Debian squeeze, x86_64 + +Please post your full QEMU command-line. + +Did you enable core dumps before launch QEMU? Do "ulimit -c +unlimited" in the same shell before running the QEMU command-line. + +If it is exiting instead of crashing I suggest launching QEMU from gdb +and catching the exit: +1. Install qemu-kvm-dbg to get the debuginfo for useful backtraces +2. Start gdb with QEMU and its usual command-line arguments: gdb +--args qemu-kvm ... +3. Set breakpoints on exit(3) and abort(2): +b exit +b abort +4. Run the VM and reproduce the exit: +r +5. When it exits you will hopefully be at an exit/abort breakpoint and +can print the stack trace: +bt + +Please post the backtrace so we have more information on how the exit happens. + +Thanks, +Stefan + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/816860 b/results/classifier/105/KVM/816860 new file mode 100644 index 00000000..f48d5f23 --- /dev/null +++ b/results/classifier/105/KVM/816860 @@ -0,0 +1,44 @@ +KVM: 0.909 +device: 0.772 +network: 0.741 +graphic: 0.713 +semantic: 0.651 +instruction: 0.643 +vnc: 0.546 +socket: 0.508 +mistranslation: 0.483 +boot: 0.476 +other: 0.358 +assembly: 0.357 + +Guest machine freezes when NFS mount goes offline + +I have a virtual KVM machine that has 2 CDROM units with ISOs mounted from a NFS mount point. When NFS server goes offline the virtual machine blocks completely instead of throwing read errors for the CDROM device. + +Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +Guest: Windows 7 professional SP 1 + +On Wed, Jul 27, 2011 at 10:09 AM, Igor Blanco <email address hidden> wrote: +> Public bug reported: +> +> I have a virtual KVM machine that has 2 CDROM units with ISOs mounted +> from a NFS mount point. When NFS server goes offline the virtual machine +> blocks completely instead of throwing read errors for the CDROM device. +> +> Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +> KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +> Guest: Windows 7 professional SP 1 + +Thanks for reporting this. There are instances where QEMU performs +blocking operations in a thread that will prevent the guest from +running. I suspect you are hitting this case and refactoring work +needs to be done to ensure that QEMU threads never block. + +Stefan + + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/819 b/results/classifier/105/KVM/819 new file mode 100644 index 00000000..81bbcae1 --- /dev/null +++ b/results/classifier/105/KVM/819 @@ -0,0 +1,88 @@ +KVM: 0.773 +other: 0.643 +vnc: 0.628 +semantic: 0.575 +instruction: 0.570 +graphic: 0.568 +device: 0.566 +network: 0.510 +assembly: 0.465 +mistranslation: 0.446 +socket: 0.437 +boot: 0.411 + +watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0] +Description of problem: +During virtual disk live move/migration, VMs get severe stuttering and even cpu soft lockups, as described here: + +https://bugzilla.kernel.org/show_bug.cgi?id=199727 + +This also happens on some of our virtual machines when i/o load inside VM is high or workload is fsync centric. + +i'm searching for a solution to mitigate this problem, i.e. i can live with the stuttering/delays of several seconds, but getting cpu soft lockups of 22s or higher is inacceptable. + +i have searched the web for a long long time now, but did not find a solution , nor did i find a way on how to troubleshoot this more in depth to find the real root cause. + +if this issue report will not getting accepted because of "non native qemu" (i.e. proxmox platform) , please tell me which qemu/distro i can/should use instead (which has easy usable live migration feature) to try reproducing the problem. +Steps to reproduce: +1. do a live migration of one or more virtual machine disks +2. watch "ioping -WWWYy test.dat" inside VM (being moved) for disk latency +3. you disk latency is heavily varying , from time to time it goes up to vaues of tens seconds, even leading to kernel messages like " kernel:[ 2155.520846] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0]" + +``` +4 KiB >>> test.dat (ext4 /dev/sda1): request=55 time=1.07 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=56 time=1.24 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=57 time=567.4 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=58 time=779.0 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=59 time=589.0 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=60 time=1.57 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=61 time=847.7 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=62 time=933.0 ms +4 KiB >>> test.dat (ext4 /dev/sda1): request=63 time=891.4 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=64 time=820.8 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=65 time=1.02 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=66 time=2.44 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=67 time=620.7 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=68 time=1.03 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=69 time=1.24 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=70 time=1.42 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=71 time=1.36 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=72 time=1.41 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=73 time=1.33 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=74 time=2.36 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=75 time=1.46 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=76 time=1.45 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=77 time=1.28 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=78 time=1.41 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=79 time=2.33 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=80 time=1.39 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=81 time=1.35 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=82 time=1.54 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=83 time=1.52 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=84 time=1.50 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=85 time=2.00 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=86 time=1.47 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=87 time=1.26 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=88 time=1.29 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=89 time=2.05 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=90 time=1.44 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=91 time=1.43 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=92 time=1.72 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=93 time=1.77 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=94 time=2.56 s + +Message from syslogd@iotest2 at Jan 14 14:51:12 ... + kernel:[ 2155.520846] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/1:0] +4 KiB >>> test.dat (ext4 /dev/sda1): request=95 time=22.5 s (slow) +4 KiB >>> test.dat (ext4 /dev/sda1): request=96 time=3.56 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=97 time=1.52 s (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=98 time=1.69 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=99 time=1.90 s +4 KiB >>> test.dat (ext4 /dev/sda1): request=100 time=1.15 s (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=101 time=890.0 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=102 time=959.6 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=103 time=926.5 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=104 time=791.5 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=105 time=577.8 ms (fast) +4 KiB >>> test.dat (ext4 /dev/sda1): request=106 time=867.7 ms (fast) +``` diff --git a/results/classifier/105/KVM/902720 b/results/classifier/105/KVM/902720 new file mode 100644 index 00000000..37d552c3 --- /dev/null +++ b/results/classifier/105/KVM/902720 @@ -0,0 +1,129 @@ +KVM: 0.364 +other: 0.349 +graphic: 0.340 +semantic: 0.332 +network: 0.315 +instruction: 0.297 +assembly: 0.293 +device: 0.274 +vnc: 0.270 +boot: 0.261 +socket: 0.216 +mistranslation: 0.215 + +TIME_MAX not set correctly for OpenBSD in qemu-common.h + +Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code. +OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit). + + CC i386-softmmu/monitor.o +/buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password': +/buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion + +qemu-common.h has... + +#ifndef TIME_MAX +#define TIME_MAX LONG_MAX +#endif + +for OpenBSD this should be INT_MAX. + +On 11/12/11 5:53 AM, Stefan Weil wrote: +> Am 11.12.2011 07:47, schrieb Brad Smith: +>> Public bug reported: +>> +>> Looking at the OpenBSD buildbot logs I noticed a warning that appears +>> to be a bug in the code. +>> OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and +>> 64-bit). +>> +>> CC i386-softmmu/monitor.o +>> /buildbot-qemu/default_openbsd_current/build/monitor.c: In function +>> 'expire_password': +>> /buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: +>> overflow in implicit constant conversion +>> +>> qemu-common.h has... +>> +>> #ifndef TIME_MAX +>> #define TIME_MAX LONG_MAX +>> #endif +>> +>> for OpenBSD this should be INT_MAX. +>> +>> ** Affects: qemu +>> Importance: Undecided +>> Status: New +> +> This needs special handling for w32 / w64, too. +> Looking at the code where TIME_MAX is used, I assume that +> more fixes are needed. The following code for example +> won't work: +> +> if (lifetime > INT_MAX) { +> +> What about using +> +> #define TIME_FOREVER -1 +> +> instead of TIME_MAX? Of course this would need additional +> code changes. +> +> Regards, +> Stefan Weil + +Gerd? + +Still looking for comment on this since you added the initial code which +has this bug in it. + +-- +This message has been scanned for viruses and +dangerous content by MailScanner, and is +believed to be clean. + + + + Hi, + +>>> Looking at the OpenBSD buildbot logs I noticed a warning that appears +>>> to be a bug in the code. +>>> OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and +>>> 64-bit). + +Ouch. Adding 64bit arch with 32bit time_t is pretty lame IMHO. There +are a bunch of years left to fix that that though. + +>>> #ifndef TIME_MAX +>>> #define TIME_MAX LONG_MAX +>>> #endif +>>> +>>> for OpenBSD this should be INT_MAX. + +Guess we'll need an #ifdef then. + +>> This needs special handling for w32 / w64, too. +>> Looking at the code where TIME_MAX is used, I assume that +>> more fixes are needed. The following code for example +>> won't work: +>> +>> if (lifetime > INT_MAX) { + +With 32bit time_t lifetime wouldn't become larger than INT_MAX anyway, +so it doesn't matter ;) + +> Still looking for comment on this since you added the initial code which +> has this bug in it. + +cheers, + Gerd + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +Since this bug report was filed OpenBSD has switched from 32-bit time_t to 64-bit time_t on all archs (yes, including 32-bit archs like i386, arm, powerpc). So instead of INT_MAX TIME_MAX should now be set to LLONG_MAX. + +This was fixed in commit e7b47c22e2df14d, which was in the 2.11.0 release. + + diff --git a/results/classifier/105/KVM/903 b/results/classifier/105/KVM/903 new file mode 100644 index 00000000..3e51b10a --- /dev/null +++ b/results/classifier/105/KVM/903 @@ -0,0 +1,368 @@ +KVM: 0.691 +other: 0.633 +mistranslation: 0.538 +graphic: 0.476 +device: 0.450 +semantic: 0.438 +vnc: 0.403 +boot: 0.367 +instruction: 0.355 +socket: 0.331 +assembly: 0.326 +network: 0.244 + +m1 MacOS panic testing lima with qemu HEAD/7.0.0 +Description of problem: +I'm trying to help the `lima` project test the latest version of lima on m1 with the latest qemu https://github.com/lima-vm/lima/issues/713 and I got a panic and was told to report back in the qemu issue tracker. + +I created a VM with 8GiB memory, and got a panic. + + +lima version: +``` +⎈ |rancher-desktop:default) ~ ❯❯❯ limactl --version ✘ 1 +limactl version HEAD-1164273 +``` + +qemu version: +``` +(⎈ |rancher-desktop:default) ~ ❯❯❯ qemu-system-aarch64 --version +QEMU emulator version 6.2.50 (v6.2.0-2380-g1416688c53) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +``` + +MacOS panic: + +``` +panic(cpu 3 caller 0xfffffe001db6ea58): vm_fault() KERN_FAILURE from guest fault on state 0xfffffe6032c98000 @sleh.c:3091 +Debugger message: panic +Memory ID: 0x6 +OS release type: User +OS version: 21A559 +Kernel version: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 +Fileset Kernelcache UUID: 3B2CA3833A09A383D66FB36667ED9CBF +Kernel UUID: 67BCB41B-BAA4-3634-8E51-B0210457E324 +iBoot version: iBoot-7429.41.5 +secure boot?: YES +Paniclog version: 13 +KernelCache slide: 0x00000000160d8000 +KernelCache base: 0xfffffe001d0dc000 +Kernel slide: 0x0000000016900000 +Kernel text base: 0xfffffe001d904000 +Kernel text exec slide: 0x00000000169e8000 +Kernel text exec base: 0xfffffe001d9ec000 +mach_absolute_time: 0x1661a3f15fc +Epoch Time: sec usec + Boot : 0x622a7219 0x00029f9b + Sleep : 0x622ba92c 0x00061dca + Wake : 0x622ba9d3 0x000ae46d + Calendar: 0x622bc0fb 0x000caf67 + +Zone info: +Foreign : 0xfffffe0025c14000 - 0xfffffe0025c28000 +Native : 0xfffffe10003bc000 - 0xfffffe30003bc000 +Readonly : 0 - 0 +Metadata : 0xfffffe64105d0000 - 0xfffffe641c53c000 +Bitmaps : 0xfffffe641c53c000 - 0xfffffe6433f6c000 +CORE 0 PVH locks held: None +CORE 1 PVH locks held: None +CORE 2 PVH locks held: None +CORE 3 PVH locks held: None +CORE 4 PVH locks held: None +CORE 5 PVH locks held: None +CORE 6 PVH locks held: None +CORE 7 PVH locks held: None +CORE 8 PVH locks held: None +CORE 9 PVH locks held: None +CORE 0: PC=0xfffffe001da72c6c, LR=0xfffffe001da72c6c, FP=0xfffffe6110abbef0 +CORE 1: PC=0xfffffe001f2cdbe0, LR=0xfffffe001f2ceb54, FP=0xfffffe611027b600 +CORE 2: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe603778bef0 +CORE 3 is the one that panicked. Check the full backtrace for details. +CORE 4: PC=0xfffffe001da72c6c, LR=0xfffffe001da72c6c, FP=0xfffffe61166fbef0 +CORE 5: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6110a6bef0 +CORE 6: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe61121cbef0 +CORE 7: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe60b4be3ef0 +CORE 8: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6032af3ef0 +CORE 9: PC=0xfffffe001da72c70, LR=0xfffffe001da72c6c, FP=0xfffffe6090a4bef0 +Panicked task 0xfffffe150e4ccd50: 17757 pages, 10 threads: pid 21141: qemu-system-aarc +Panicked thread: 0xfffffe1515ae87d8, backtrace: 0xfffffe60d51e3300, tid: 979402 + lr: 0xfffffe001da3e488 fp: 0xfffffe60d51e3370 + lr: 0xfffffe001da3e158 fp: 0xfffffe60d51e33e0 + lr: 0xfffffe001db7a558 fp: 0xfffffe60d51e3400 + lr: 0xfffffe001db6d2d4 fp: 0xfffffe60d51e3480 + lr: 0xfffffe001db6ac9c fp: 0xfffffe60d51e3540 + lr: 0xfffffe001d9f37f8 fp: 0xfffffe60d51e3550 + lr: 0xfffffe001da3ddcc fp: 0xfffffe60d51e38f0 + lr: 0xfffffe001da3ddcc fp: 0xfffffe60d51e3960 + lr: 0xfffffe001e23c748 fp: 0xfffffe60d51e3980 + lr: 0xfffffe001db6ea58 fp: 0xfffffe60d51e39e0 + lr: 0xfffffe001db6e5dc fp: 0xfffffe60d51e3a50 + lr: 0xfffffe001d9fe828 fp: 0xfffffe60d51e3a60 + lr: 0xfffffe001db823f4 fp: 0xfffffe60d51e3e50 + lr: 0xfffffe001db6b140 fp: 0xfffffe60d51e3f10 + lr: 0xfffffe001d9f37f8 fp: 0xfffffe60d51e3f20 + +last started kext at 1368960011: com.apple.filesystems.smbfs 4.0 (addr 0xfffffe001d8ea490, size 64483) +loaded kexts: +com.apple.filesystems.smbfs 4.0 +com.apple.filesystems.autofs 3.0 +com.apple.fileutil 20.036.15 +com.apple.UVCService 1 +com.apple.driver.AppleUSBTopCaseDriver 5010.1 +com.apple.iokit.SCSITaskUserClient 452.30.4 +com.apple.driver.AppleIntelI210Ethernet 2.3.1 +com.apple.driver.AppleBiometricServices 1 +com.apple.driver.CoreKDL 1 +com.apple.driver.AppleTopCaseHIDEventDriver 5010.1 +com.apple.driver.SEPHibernation 1 +com.apple.driver.BCMWLANFirmware4387.Hashstore 1 +com.apple.driver.DiskImages.ReadWriteDiskImage 493.0.0 +com.apple.driver.DiskImages.UDIFDiskImage 493.0.0 +com.apple.driver.DiskImages.RAMBackingStore 493.0.0 +com.apple.driver.DiskImages.FileBackingStore 493.0.0 +com.apple.filesystems.apfs 1933.41.2 +com.apple.driver.AppleUSBDeviceNCM 5.0.0 +com.apple.driver.AppleThunderboltIP 4.0.3 +com.apple.driver.AppleFileSystemDriver 3.0.1 +com.apple.nke.l2tp 1.9 +com.apple.filesystems.tmpfs 1 +com.apple.filesystems.lifs 1 +com.apple.IOTextEncryptionFamily 1.0.0 +com.apple.filesystems.hfs.kext 582.40.4 +com.apple.security.BootPolicy 1 +com.apple.BootCache 40 +com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0 +com.apple.AppleFSCompression.AppleFSCompressionTypeDataless 1.0.0d1 +com.apple.driver.AppleCS42L84Audio 502.6 +com.apple.driver.ApplePMP 1 +com.apple.driver.AppleSmartIO2 1 +com.apple.driver.AppleSN012776Amp 502.6 +com.apple.AppleEmbeddedSimpleSPINORFlasher 1 +com.apple.driver.AppleT6000SOCTuner 1 +com.apple.driver.AppleT6000CLPCv3 1 +com.apple.driver.AppleSmartBatteryManager 161.0.0 +com.apple.driver.AppleALSColorSensor 1.0.0d1 +com.apple.driver.AppleAOPVoiceTrigger 100.1 +com.apple.driver.ApplePMPFirmware 1 +com.apple.driver.AppleMCDP29XXUpdateSupport 1 +com.apple.driver.AppleM68Buttons 1.0.0d1 +com.apple.driver.AppleSamsungSerial 1.0.0d1 +com.apple.driver.AppleSerialShim 1 +com.apple.driver.usb.AppleSynopsysUSB40XHCI 1 +com.apple.driver.AppleSDXC 3.1.1 +com.apple.driver.AppleSPMIPMU 1.0.1 +com.apple.AGXG13X 187.57 +com.apple.driver.AppleAVD 415 +com.apple.driver.AppleAVE2 501.6.9 +com.apple.driver.AppleJPEGDriver 4.7.8 +com.apple.driver.AppleProResHW 126.2.0 +com.apple.driver.AppleMobileDispT600X-DCP 140.0 +com.apple.driver.AppleDPDisplayTCON 1 +com.apple.driver.AppleEventLogHandler 1 +com.apple.driver.AppleS5L8960XNCO 1 +com.apple.driver.AppleT6001PMGR 1 +com.apple.driver.AppleS8000AES 1 +com.apple.driver.AppleS8000DWI 1.0.0d1 +com.apple.driver.AppleInterruptControllerV2 1.0.0d1 +com.apple.driver.AppleT8110DART 1 +com.apple.driver.AppleBluetoothModule 1 +com.apple.driver.AppleBCMWLANBusInterfacePCIe 1 +com.apple.driver.AppleS5L8920XPWM 1.0.0d1 +com.apple.driver.AudioDMAController-T600x 100.51 +com.apple.driver.AppleT6000DART 1 +com.apple.driver.AppleSPIMC 1 +com.apple.driver.AppleS5L8940XI2C 1.0.0d2 +com.apple.driver.AppleT6000 1 +com.apple.iokit.IOUserEthernet 1.0.1 +com.apple.driver.usb.AppleUSBUserHCI 1 +com.apple.iokit.IOKitRegistryCompatibility 1 +com.apple.iokit.EndpointSecurity 1 +com.apple.driver.AppleDiskImages2 126.40.1 +com.apple.AppleSystemPolicy 2.0.0 +com.apple.nke.applicationfirewall 402 +com.apple.kec.InvalidateHmac 1 +com.apple.kec.AppleEncryptedArchive 1 +com.apple.driver.driverkit.serial 6.0.0 +com.apple.kext.triggers 1.0 +com.apple.driver.AppleUSBMergeNub 900.4.2 +com.apple.driver.usb.cdc.ecm 5.0.0 +com.apple.driver.usb.cdc.acm 5.0.0 +com.apple.driver.usb.serial 6.0.0 +com.apple.driver.usb.cdc.ncm 5.0.0 +com.apple.iokit.IOAVBFamily 1010.2 +com.apple.plugin.IOgPTPPlugin 1000.11 +com.apple.driver.usb.IOUSBHostHIDDevice 1.2 +com.apple.driver.usb.cdc 5.0.0 +com.apple.driver.AppleUSBAudio 412.8 +com.apple.iokit.IOAudioFamily 300.10 +com.apple.vecLib.kext 1.2.0 +com.apple.iokit.IOEthernetAVBController 1.1.0 +com.apple.driver.usb.AppleUSBXHCIPCI 1.2 +com.apple.driver.AppleMesaSEPDriver 100.99 +com.apple.iokit.IOBiometricFamily 1 +com.apple.driver.AppleHIDKeyboard 228 +com.apple.driver.AppleHSBluetoothDriver 5010.1 +com.apple.driver.IOBluetoothHIDDriver 9.0.0 +com.apple.driver.AppleActuatorDriver 5400.25 +com.apple.driver.AppleMultitouchDriver 5400.25 +com.apple.driver.AppleThunderboltPCIUpAdapter 4.1.1 +com.apple.driver.AppleThunderboltDPOutAdapter 8.5.0 +com.apple.driver.AppleSEPHDCPManager 1.0.1 +com.apple.driver.AppleTrustedAccessory 1 +com.apple.iokit.AppleSEPGenericTransfer 1 +com.apple.driver.DiskImages.KernelBacked 493.0.0 +com.apple.driver.AppleXsanScheme 3 +com.apple.driver.usb.networking 5.0.0 +com.apple.driver.AppleThunderboltUSBDownAdapter 1.0.4 +com.apple.driver.AppleThunderboltPCIDownAdapter 4.1.1 +com.apple.driver.AppleThunderboltDPInAdapter 8.5.0 +com.apple.driver.AppleThunderboltDPAdapterFamily 8.5.0 +com.apple.nke.ppp 1.9 +com.apple.driver.AppleHIDTransportSPI 5400.30 +com.apple.driver.AppleHIDTransport 5400.30 +com.apple.driver.AppleInputDeviceSupport 5400.30 +com.apple.driver.AppleBSDKextStarter 3 +com.apple.filesystems.hfs.encodings.kext 1 +com.apple.driver.AppleConvergedIPCOLYBTControl 1 +com.apple.driver.AppleConvergedPCI 1 +com.apple.driver.AppleBluetoothDebug 1 +com.apple.driver.AppleBTM 1.0.1 +com.apple.driver.AppleDiagnosticDataAccessReadOnly 1.0.0 +com.apple.driver.AppleCSEmbeddedAudio 502.6 +com.apple.driver.AppleDCPDPTXProxy 1.0.0 +com.apple.driver.DCPDPFamilyProxy 1 +com.apple.driver.ApplePassthroughPPM 3.0 +com.apple.driver.AppleAOPAudio 102.2 +com.apple.driver.AppleEmbeddedAudio 502.6 +com.apple.iokit.AppleARMIISAudio 100.1 +com.apple.driver.AppleSPU 1 +com.apple.iokit.IONVMeFamily 2.1.0 +com.apple.driver.AppleNANDConfigAccess 1.0.0 +com.apple.AGXFirmwareKextG13XRTBuddy 187.57 +com.apple.AGXFirmwareKextRTBuddy64 187.57 +com.apple.driver.AppleHPM 3.4.4 +com.apple.driver.DCPAVFamilyProxy 1 +com.apple.driver.AppleStockholmControl 1.0.0 +com.apple.driver.AppleT6000TypeCPhy 1 +com.apple.driver.AppleT8103TypeCPhy 1 +com.apple.driver.AppleUSBXDCIARM 1.0 +com.apple.driver.AppleUSBXDCI 1.0 +com.apple.iokit.IOUSBDeviceFamily 2.0.0 +com.apple.driver.usb.AppleSynopsysUSBXHCI 1 +com.apple.driver.usb.AppleUSBXHCI 1.2 +com.apple.driver.AppleEmbeddedUSBHost 1 +com.apple.driver.usb.AppleUSBHub 1.2 +com.apple.driver.usb.AppleUSBHostCompositeDevice 1.2 +com.apple.driver.AppleDialogPMU 1.0.1 +com.apple.driver.AppleSPMI 1.0.1 +com.apple.driver.usb.AppleUSBHostPacketFilter 1.0 +com.apple.iokit.IOGPUFamily 35.11 +com.apple.iokit.IOMobileGraphicsFamily-DCP 343.0.0 +com.apple.driver.AppleDCP 1 +com.apple.driver.AppleFirmwareKit 1 +com.apple.iokit.IOMobileGraphicsFamily 343.0.0 +com.apple.driver.AppleSART 1 +com.apple.driver.ApplePMGR 1 +com.apple.driver.AppleARMWatchdogTimer 1 +com.apple.driver.AppleDisplayCrossbar 1.0.0 +com.apple.iokit.IODisplayPortFamily 1.0.0 +com.apple.driver.AppleTypeCPhy 1 +com.apple.driver.AppleThunderboltNHI 7.2.8 +com.apple.driver.AppleT6000PCIeC 1 +com.apple.iokit.IOThunderboltFamily 9.3.2 +com.apple.driver.ApplePIODMA 1 +com.apple.driver.AppleT600xPCIe 1 +com.apple.driver.AppleMultiFunctionManager 1 +com.apple.driver.AppleBluetoothDebugService 1 +com.apple.driver.AppleBCMWLANCore 1.0.0 +com.apple.iokit.IO80211Family 1200.12.2b1 +com.apple.driver.IOImageLoader 1.0.0 +com.apple.driver.AppleOLYHAL 1 +com.apple.driver.corecapture 1.0.4 +com.apple.driver.AppleEmbeddedPCIE 1 +com.apple.driver.AppleMCA2-T600x 600.95 +com.apple.driver.AppleEmbeddedAudioLibs 100.9.1 +com.apple.driver.AppleFirmwareUpdateKext 1 +com.apple.driver.AppleH13CameraInterface 4.79.0 +com.apple.driver.AppleH10PearlCameraInterface 17.0.3 +com.apple.driver.AppleGPIOICController 1.0.2 +com.apple.driver.AppleFireStormErrorHandler 1 +com.apple.driver.AppleMobileApNonce 1 +com.apple.iokit.IOTimeSyncFamily 1000.11 +com.apple.driver.DiskImages 493.0.0 +com.apple.iokit.IOGraphicsFamily 593 +com.apple.iokit.IOBluetoothSerialManager 9.0.0 +com.apple.iokit.IOBluetoothHostControllerUSBTransport 9.0.0 +com.apple.iokit.IOBluetoothHostControllerUARTTransport 9.0.0 +com.apple.iokit.IOBluetoothHostControllerTransport 9.0.0 +com.apple.driver.IOBluetoothHostControllerPCIeTransport 9.0.0 +com.apple.iokit.IOBluetoothFamily 9.0.0 +com.apple.driver.FairPlayIOKit 68.13.0 +com.apple.iokit.CoreAnalyticsFamily 1 +com.apple.iokit.CSRBluetoothHostControllerUSBTransport 9.0.0 +com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport 9.0.0 +com.apple.driver.AppleSSE 1.0 +com.apple.driver.AppleSEPKeyStore 2 +com.apple.driver.AppleUSBTDM 532.40.7 +com.apple.iokit.IOUSBMassStorageDriver 209.40.6 +com.apple.iokit.IOPCIFamily 2.9 +com.apple.iokit.IOSCSIBlockCommandsDevice 452.30.4 +com.apple.iokit.IOSCSIArchitectureModelFamily 452.30.4 +com.apple.driver.AppleIPAppender 1.0 +com.apple.driver.AppleFDEKeyStore 28.30 +com.apple.driver.AppleEffaceableStorage 1.0 +com.apple.driver.AppleCredentialManager 1.0 +com.apple.driver.KernelRelayHost 1 +com.apple.iokit.IOUSBHostFamily 1.2 +com.apple.driver.AppleUSBHostMergeProperties 1.2 +com.apple.driver.usb.AppleUSBCommon 1.0 +com.apple.driver.AppleSMC 3.1.9 +com.apple.driver.RTBuddy 1.0.0 +com.apple.driver.AppleEmbeddedTempSensor 1.0.0 +com.apple.driver.AppleARMPMU 1.0 +com.apple.iokit.IOAccessoryManager 1.0.0 +com.apple.driver.AppleOnboardSerial 1.0 +com.apple.iokit.IOSkywalkFamily 1.0 +com.apple.driver.mDNSOffloadUserClient 1.0.1b8 +com.apple.iokit.IONetworkingFamily 3.4 +com.apple.iokit.IOSerialFamily 11 +com.apple.driver.AppleSEPManager 1.0.1 +com.apple.driver.AppleA7IOP 1.0.2 +com.apple.driver.IOSlaveProcessor 1 +com.apple.driver.AppleBiometricSensor 2 +com.apple.iokit.IOHIDFamily 2.0.0 +com.apple.driver.AppleANELoadBalancer 5.33.2 +com.apple.driver.AppleH11ANEInterface 5.33.0 +com.apple.AUC 1.0 +com.apple.iokit.IOAVFamily 1.0.0 +com.apple.iokit.IOHDCPFamily 1.0.0 +com.apple.iokit.IOCECFamily 1 +com.apple.iokit.IOAudio2Family 1.0 +com.apple.driver.AppleIISController 100.1 +com.apple.driver.AppleAudioClockLibs 100.9.1 +com.apple.driver.AppleM2ScalerCSCDriver 265.0.0 +com.apple.iokit.IOSurface 302.9 +com.apple.driver.IODARTFamily 1 +com.apple.security.quarantine 4 +com.apple.security.sandbox 300.0 +com.apple.kext.AppleMatch 1.0.0d1 +com.apple.driver.AppleMobileFileIntegrity 1.0.5 +com.apple.security.AppleImage4 4.1.0 +com.apple.kext.CoreTrust 1 +com.apple.iokit.IOCryptoAcceleratorFamily 1.0.1 +com.apple.driver.AppleARMPlatform 1.0.2 +com.apple.iokit.IOStorageFamily 2.1 +com.apple.iokit.IOSlowAdaptiveClockingFamily 1.0.0 +com.apple.iokit.IOReportFamily 47 +com.apple.kec.pthread 1 +com.apple.kec.Libm 1 +com.apple.kec.corecrypto 12.0 + + + +** Stackshot Succeeded ** Bytes Traced 478480 (Uncompressed 1208976) ** +``` +Steps to reproduce: +1. See https://github.com/lima-vm/lima/issues/713 +Additional information: + diff --git a/results/classifier/105/KVM/905095 b/results/classifier/105/KVM/905095 new file mode 100644 index 00000000..262e7c51 --- /dev/null +++ b/results/classifier/105/KVM/905095 @@ -0,0 +1,391 @@ +KVM: 0.766 +graphic: 0.712 +device: 0.709 +mistranslation: 0.708 +instruction: 0.692 +semantic: 0.683 +assembly: 0.681 +boot: 0.675 +network: 0.669 +socket: 0.659 +other: 0.658 +vnc: 0.644 + +qemu-img can't convert vmdk file: Operation not permitted + +There is no reason why the vdmk image can't be converted. Even running it as root does not help. + +$ ls -lh +insgesamt 60G +-rw-rw-rw- 1 root root 479M 2011-09-10 17:47 freetz-linux-1.2.1-disk1.vmdk + +$ sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +I get a similar Error when I try to rum vmdk images directly. After adding a new machine and adding vmdk disks with virt-manager, it tells me when I start the virtual machine: +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +kvm: -drive file=/var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk: Invalid argument + +Runnung raw images works perfectly for me. + +Hint: i have a symlink set: +/var/lib/libvirt$ ls -lh +insgesamt 12K +drwxr-xr-x 2 root root 4,0K 2011-07-26 14:30 boot +lrwxrwxrwx 1 root root 9 2011-08-19 10:47 images -> /home/vms +drwxr-xr-x 2 root root 4,0K 2011-08-19 09:38 network +drwxr-xr-x 5 libvirt-qemu kvm 4,0K 2011-12-16 04:34 qemu + +but this should not be the reason hopefully + +ProblemType: Bug +DistroRelease: Ubuntu 11.04 +Package: qemu-kvm 0.14.0+noroms-0ubuntu4.4 +ProcVersionSignature: Ubuntu 2.6.38-13.52-generic 2.6.38.8 +Uname: Linux 2.6.38-13-generic x86_64 +Architecture: amd64 +CheckboxSubmission: 8f12e98536291f59719792d89958b124 +CheckboxSystem: d00f84de8a555815fa1c4660280da308 +Date: Fri Dec 16 04:24:10 2011 +InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1) +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: Dell Inc. Latitude E5510 +ProcEnviron: + LANGUAGE=de_DE:en + PATH=(custom, user) + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=503213e4-5136-4e60-8a02-7cbd0123dca8 ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: Upgraded to natty on 2011-08-18 (119 days ago) +dmi.bios.date: 09/08/2011 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: A11 +dmi.board.name: 023HKR +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 9 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2011:svnDellInc.:pnLatitudeE5510:pvr0001:rvnDellInc.:rn023HKR:rvrA00:cvnDellInc.:ct9:cvr: +dmi.product.name: Latitude E5510 +dmi.product.version: 0001 +dmi.sys.vendor: Dell Inc. + + + +I just saw that the image format in my last comment was not set right. After changing it from qcow2 to vmdk I get this error when starting the machine: + +Error starting domain: operation failed: failed to retrieve chardev info in qemu with 'info chardev' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/engine.py", line 956, in asyncfunc + vm.startup() + File "/usr/share/virt-manager/virtManager/domain.py", line 1048, in startup + self._backend.create() + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 330, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: operation failed: failed to retrieve chardev info in qemu with 'info chardev' + +To reproduce the problem feel free to download this image: +http://sourceforge.net/projects/freetz-linux/ + +here's the xml file of the virtual machine + +same on a fresh installed up to date ubuntu 11.10: +sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +up-to-date debian 6.0 says: +# qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img +qemu-img: error while reading + +debian testing says: +qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +debian sid says: +qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img +*** glibc detected *** qemu-img: double free or corruption (top): 0x000000000755cd60 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x72656)[0x2b78929df656] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x2b78929e438c] +qemu-img[0x41c4a2] +qemu-img[0x41d1e6] +qemu-img[0x40e6d9] +qemu-img[0x40f247] +qemu-img[0x4055f1] +qemu-img[0x4068ad] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x2b789298bead] +qemu-img[0x404efd] +======= Memory map: ======== +00400000-0045a000 r-xp 00000000 91:e6 114343429 /usr/bin/qemu-img +0065a000-0065f000 rw-p 0005a000 91:e6 114343429 /usr/bin/qemu-img +0065f000-00a60000 rw-p 0065f000 00:00 0 +0755a000-0757b000 rw-p 0755a000 00:00 0 [heap] +2b7891471000-2b7891490000 r-xp 00000000 91:e6 254542713 /lib/x86_64-linux-gnu/ld-2.13.so +2b7891490000-2b7891492000 rw-p 2b7891490000 00:00 0 +2b7891690000-2b7891691000 r--p 0001f000 91:e6 254542713 /lib/x86_64-linux-gnu/ld-2.13.so +2b7891691000-2b7891692000 rw-p 00020000 91:e6 254542713 /lib/x86_64-linux-gnu/ld-2.13.so +2b7891692000-2b7891693000 rw-p 2b7891692000 00:00 0 +2b7891693000-2b789169a000 r-xp 00000000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b789169a000-2b7891899000 ---p 00007000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b7891899000-2b789189a000 r--p 00006000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b789189a000-2b789189b000 rw-p 00007000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b789189b000-2b78918b2000 r-xp 00000000 91:e6 89718972 /usr/lib/libz.so.1.2.3.4 +2b78918b2000-2b7891ab1000 ---p 00017000 91:e6 89718972 /usr/lib/libz.so.1.2.3.4 +2b7891ab1000-2b7891ab2000 rw-p 00016000 91:e6 89718972 /usr/lib/libz.so.1.2.3.4 +2b7891ab2000-2b7891ab3000 rw-p 2b7891ab2000 00:00 0 +2b7891ab3000-2b7891ace000 r-xp 00000000 91:e6 115417965 /usr/lib/librbd.so.1.0.0 +2b7891ace000-2b7891ccd000 ---p 0001b000 91:e6 115417965 /usr/lib/librbd.so.1.0.0 +2b7891ccd000-2b7891cce000 rw-p 0001a000 91:e6 115417965 /usr/lib/librbd.so.1.0.0 +2b7891cce000-2b7891eca000 r-xp 00000000 91:e6 115417963 /usr/lib/librados.so.2.0.0 +2b7891eca000-2b78920ca000 ---p 001fc000 91:e6 115417963 /usr/lib/librados.so.2.0.0 +2b78920ca000-2b78920d9000 rw-p 001fc000 91:e6 115417963 /usr/lib/librados.so.2.0.0 +2b78920d9000-2b78920ed000 rw-p 2b78920d9000 00:00 0 +2b78920ed000-2b7892147000 r-xp 00000000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b7892147000-2b7892347000 ---p 0005a000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b7892347000-2b7892349000 r--p 0005a000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b7892349000-2b789234a000 rw-p 0005c000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b789234a000-2b789234b000 rw-p 2b789234a000 00:00 0 +2b789234b000-2b789234f000 r-xp 00000000 91:e6 152502901 /lib/libuuid.so.1.3.0 +2b789234f000-2b789254e000 ---p 00004000 91:e6 152502901 /lib/libuuid.so.1.3.0 +2b789254e000-2b789254f000 rw-p 00003000 91:e6 152502901 /lib/libuuid.so.1.3.0 +2b789254f000-2b7892550000 r-xp 00000000 91:e6 254542270 /lib/x86_64-linux-gnu/libaio.so.1.0.1 +2b7892550000-2b789274f000 ---p 00001000 91:e6 254542270 /lib/x86_64-linux-gnu/libaio.so.1.0.1 +2b789274f000-2b7892750000 rw-p 00000000 91:e6 254542270 /lib/x86_64-linux-gnu/libaio.so.1.0.1 +2b7892750000-2b7892767000 r-xp 00000000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892767000-2b7892966000 ---p 00017000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892966000-2b7892967000 r--p 00016000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892967000-2b7892968000 rw-p 00017000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892968000-2b789296d000 rw-p 2b7892968000 00:00 0 +2b789296d000-2b7892ae7000 r-xp 00000000 91:e6 254542727 /lib/x86_64-linux-gnu/libc-2.13.so +2b7892ae7000-2b7892ce7000 ---p 0017a000 91:e6 254542727 /lib/x86_64-linux-gnu/libc-2.13.so +2b7892ceAborted + + +seems to be an older problem: +https://bugzilla.redhat.com/show_bug.cgi?id=548723 + +still getting the error while trying to convert a vmdk + +how to proceed? + +I just generated OVA from vsphere client, then I untarred it and I got a ovf and a vmdk file, how do I convert the vmdk to a readable format by kvm? + +Angelo, a workaround for me was to run the freetz image (which in fact is an ubuntu image) with VirtalBox. Then I booted the Machine with a systemrescuecd CD. + +In systemrescuecd I extracted the disk image using the dd command (disk druid). You can netcat the raw image via network to your KVM machine. The raw image booted without any problems in KVM. + +Hope this works for you. + +Confirmed on ubuntu 11.10: +>> qemu-img convert ZendTo-Ubuntu-x64-disk1.vmdk -O raw zend.img +qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk' + + +Hello, +Could someone please comment on this? There are blogs and such all over the internet talking about how easy it is to use qemu-img convert to convert VMware vmdk's to KVM qcow2's (or other formats). However, every time I do this, no matter what version of Linux or qemu-img I am using, it either a) produces an image but that is only a few MBs and thus obviously unbootable; or b) has the error in comment #9 (Operation not permitted). I see thomas303's workaround but that obviously sounds pretty harsh to be doing on a regular basis as we are looking to support our product on both VMware and KVM. Will this inability to convert vmdk to qcow2 be addressed in qemu soon? + +@Neil, + +it looks like the 2011 google summer of code project did not succeed. I don't know of anyone else working on this problem right now. + +Actually support upstream has improved a lot in recent qemu (thanks to IBM), and Red Hat are planning on doing further work in this area. + +Right now / with old qemu, the best thing is to convert your proprietary vmdk files to a portable format, ie. raw or qcow2, and use that instead. + +I retried with ubuntu 16.04, qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.4). + +While the original file (freetz vmdk) is not available (they use .ova now), I got another .vmdk file from +http://www.osboxes.org/debian/#debian-8-5-vmware + +qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O raw test.raw +qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O qcow2 test.qcow2 + +Both worked, and I could boot the system I converted from .vmdk using qemu-kvm. + +Looks as if this issue got fixed, finally. + + +I did the same task on totally different images recently and it worked fine. +Thanks for bumping that old bug so we can close it. + +That "Debian 8.5 (64bit).vmdk" also works fine with the qemu-img from upstream master branch ==> I'm closing this ticket now for upstream, too. + +Description of problem: + +qemu-img convert cannot convert a VMDK4 format file to (eg) raw (or +anything else). It silently produces a large file that mostly +contains zero bytes, and is completely unusable. + +Version-Release number of selected component (if applicable): + +Tested with qemu-img 0.10.5, 0.11.0, and +git d9a50a366f2178 (2009-12-11). + +How reproducible: + +Always. + +Steps to Reproduce: +1. Export to OVF from VMWare vSphere / ESX 4.0.0. +2. Copy the resultant disk image to a Fedora machine. +3. Check the SHA1 sums (from *.mf file) to make sure image was not + corrupted during the copy. +4. Run: + qemu-img convert -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw +5. Try to mount / use the resulting raw file, eg. using guestfish. + +Actual results: + +The raw file contains mostly zeroes, see below. It contains zeroes +where there should be partition tables, superblocks etc. and so is +totally unusable. + +Expected results: + +A usable disk image. + +Additional info: + +Compare the entropy of the VMDK file with the resulting raw disk. +I would expect the entropy to be about the same, but you can see the +raw disk is mostly compressible (zeroes). + + $ ls -l TestLinux-disk1.vmdk + -rw-rw-r-- 1 rjones rjones 887312896 2009-12-18 10:35 TestLinux-disk1.vmdk + $ gzip -c TestLinux-disk1.vmdk | wc -c + 860846320 + $ gzip -c TestLinux-disk1.raw | wc -c + 8744715 + +VMWare's OVF metadata says the following about the disk format: + + <References> + <File ovf:href="TestLinux-disk1.vmdk" + ovf:id="file1" ovf:size="887312896" /> + </References> + <DiskSection> + <Info>Virtual disk information</Info> + <Disk ovf:capacity="8" + ovf:capacityAllocationUnits="byte * 2^30" + ovf:diskId="vmdisk1" ovf:fileRef="file1" + ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" /> + </DiskSection> + +qemu-img 0.10.5 fails in a different way. It gives the error +message: + + qemu-img: error while reading + +qemu-img >= 0.11.0 fail silently, no error message or error code. + +I've tried this with several disk images exported from vSphere 4 +and they have all failed to convert in the same way. + +Test files (at time of writing these are STILL UPLOADING, with ETA +of 2009-12-19). + +http://homes.merjis.com/~rich/TestLinux-disk1.vmdk + SHA1: 2C81BAE89210B075ACC51DA9D025935470149D55 +http://homes.merjis.com/~rich/TestLinux.ovf + SHA1: 30831689B8C6F1B1A1FCBB728769B5F71056A580 + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +You don't happen to know if this reproduces with qemu-img > 0.12.x or have a test image I can convert to reproduce handy? + +Nothing much has changed in the qemu vmdk block +driver since I looked at it before (I just checked upstream +git), so it's very likely to be still broken. + +I have some VMDK images, but I warn you that they +are very large! If you have somewhere I can upload +them to, I can send some your way ... + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +I just checked upstream git for the driver again, +and apart from code cleanups the code is still the +same as ever. Therefore moving the bug -> Rawhide. + +Updated links: +http://oirase.annexia.org/tmp/TestLinux-disk1.vmdk + SHA1: 2c81bae89210b075acc51da9d025935470149d55 +http://oirase.annexia.org/tmp/TestLinux.ovf + SHA1: 30831689b8c6f1b1a1fcbb728769b5f71056a580 + +Latest qemu-img no longer silently converts to zeroes. Instead +it gives a strange error: + +$ qemu-img convert -f vmdk -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw +qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'TestLinux-disk1.vmdk' + +> qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted + +This is probably because qemu-img.c code expects brdv_open() to return an errno value + + ret = bdrv_open(bs, filename, flags, drv); + if (ret < 0) { + error_report("Could not open '%s': %s", filename, strerror(-ret)); + goto fail; + } + +while the vmdk_open function just returns -1 for everything: + + ... + return 0; + fail: + qemu_free(s->l1_backup_table); + qemu_free(s->l1_table); + qemu_free(s->l2_cache); + return -1; +} + +and by coincidence, '1 == EPERM'. There are ~4 codepaths in vmdk_open that could fail, the VMDK magic check and then a couple of reads of metadata + +There is hope: +http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg03130.html +http://lists.gnu.org/archive/html/qemu-devel/2011-06/threads.html#00033 + +The vmdk from "Export as OVF..." doesn't work. +# qemu-img convert -O raw esx4.1-rhel5.7-i386-disk1.vmdk test-vmdk.raw +qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk' +qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk' + +I copied a vmdk file from ESX storage directly,and then use qemu-img to convert it to raw,it works. +# qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw +# ll test-vmdk.raw +-rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw + +(In reply to comment #11) +> I copied a vmdk file from ESX storage directly,and then use qemu-img to convert +> it to raw,it works. +> # qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw +> # ll test-vmdk.raw +> -rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw + +*-flat.vmdk files are not VMDK. They are just raw files +which happen to have a .vmdk extension. So this doesn't +really prove anything. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This bug has lingered for forever, so I don't think tracking this in Fedora is going to solve much. + +Rich, if you can still reproduce this with qemu.git, I'd recommend filing an upstream bug and publishing a reproducer image like you did before. + diff --git a/results/classifier/105/KVM/916 b/results/classifier/105/KVM/916 new file mode 100644 index 00000000..2c1497db --- /dev/null +++ b/results/classifier/105/KVM/916 @@ -0,0 +1,24 @@ +KVM: 0.977 +instruction: 0.923 +graphic: 0.881 +device: 0.851 +semantic: 0.689 +vnc: 0.607 +socket: 0.514 +network: 0.497 +boot: 0.468 +mistranslation: 0.329 +other: 0.326 +assembly: 0.259 + +QEMU system emulators immediately crash on AMD hosts when KVM is used +Description of problem: +``` +$ qemu-system-x86_64 -accel kvm +qemu-system-x86_64: ../target/i386/kvm/kvm-cpu.c:105: kvm_cpu_xsave_init: Assertion `esa->size == eax' failed. +Aborted (core dumped) +``` + +This is a regression introduced in + +https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg04312.html diff --git a/results/classifier/105/KVM/920772 b/results/classifier/105/KVM/920772 new file mode 100644 index 00000000..6b37d26b --- /dev/null +++ b/results/classifier/105/KVM/920772 @@ -0,0 +1,55 @@ +KVM: 0.529 +device: 0.418 +semantic: 0.361 +graphic: 0.316 +other: 0.311 +boot: 0.169 +mistranslation: 0.161 +instruction: 0.153 +socket: 0.126 +assembly: 0.108 +network: 0.091 +vnc: 0.067 + +Win98SE glitches RHEL6.2/CentOS6.2 QEMU + +I'm not sure if this is something anyone will be interested in, +but I ran into some glitches setting up a Windows 98 SE +QEMU VM with a relatively recent version. Needed this +to restore an ancient backup and got it working well +enough to get the job done. + +Versions +======== + +Distro: CentOS 6.2 + +Kernel: upstream 3.1.8 + +QEMU: +gpxe-roms-qemu-0.9.7-6.9.el6.noarch +qemu-img-0.12.1.2-2.209.el6_2.1.x86_64 +qemu-kvm-0.12.1.2-2.209.el6_2.1.x86_64 + +Glitches: + +1) Doesn't work in KVM mode, screen goes black +just after installer is finishing up and switching to +Win98. Saw this issue has been around for awhile. + +2) Got it working in QEMU mode, but BIOS plug-n-play +driver fails. This prevents other devices from working. + +a) CDROM not recognized + +b) Realtek 8139C driver (installed separately after +Win98) not recognized. + +I don't need these issues fixed, just reporting the +in case it's of interest and/or helpful. Can provide +more detail on request. + +QEMU 0.12 is pretty much outdated nowadays - can you still reproduce these issues with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/922355 b/results/classifier/105/KVM/922355 new file mode 100644 index 00000000..c3b63894 --- /dev/null +++ b/results/classifier/105/KVM/922355 @@ -0,0 +1,27 @@ +KVM: 0.881 +device: 0.810 +socket: 0.803 +vnc: 0.772 +instruction: 0.753 +graphic: 0.708 +mistranslation: 0.695 +network: 0.694 +semantic: 0.487 +boot: 0.298 +assembly: 0.275 +other: 0.264 + +qemu crashes when invoked on Pandaboard + +root@omap:~# uname -a +Linux omap 3.1.6-x6 #1 SMP Thu Dec 22 11:17:51 UTC 2011 armv7l armv7l +armv7l GNU/Linux + +root@omap:~# qemu +Could not initialize KVM, will disable KVM support +/build/buildd/qemu-kvm-0.14.1+noroms/tcg/arm/tcg-target.c:848: tcg fatal error + +QEMU 0.14 is pretty much outdated nowadays ... Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/954 b/results/classifier/105/KVM/954 new file mode 100644 index 00000000..aa1140a4 --- /dev/null +++ b/results/classifier/105/KVM/954 @@ -0,0 +1,1270 @@ +KVM: 0.199 +graphic: 0.154 +other: 0.115 +vnc: 0.114 +semantic: 0.098 +mistranslation: 0.097 +socket: 0.082 +device: 0.081 +assembly: 0.080 +boot: 0.071 +instruction: 0.064 +network: 0.063 + +qemu 6.2.0 with SEV in x86_64 initrd unpack ? +Description of problem: +The guest kernel panic from qemu 6.2.0, works fine on 6.0.0 and 6.1.0, works fine without SEV on 6.2.0 too. + +From our research it seems that initrd is not unpacked and initialized in an SEV context on 6.2.0 as we can see in logs without SEV that the initrd is well unpacked. Please have a look on additional informations for all the logs. + +We can see this crash during guest initialization: +``` +[ 0.252891] VFS: Cannot open root device \(null)\ or unknown-block(0,0): error -6 +[ 0.253054] Please append a correct \root=\ boot option; here are the available partitions: +[ 0.253179] 0100 4096 ram0 +[ 0.253181] (driver?) +[ 0.253285] 0101 4096 ram1 +[ 0.253286] (driver?) +[ 0.253389] 0102 4096 ram2 +[ 0.253390] (driver?) +[ 0.253490] 0103 4096 ram3 +[ 0.253491] (driver?) +[ 0.253595] 0104 4096 ram4 +[ 0.253596] (driver?) +[ 0.253708] 0105 4096 ram5 +[ 0.253709] (driver?) +[ 0.253816] 0106 4096 ram6 +[ 0.253817] (driver?) +[ 0.253965] 0107 4096 ram7 +[ 0.253967] (driver?) +[ 0.254065] 0108 4096 ram8 +[ 0.254066] (driver?) +[ 0.254170] 0109 4096 ram9 +[ 0.254171] (driver?) +[ 0.254274] 010a 4096 ram10 +[ 0.254276] (driver?) +[ 0.254392] 010b 4096 ram11 +[ 0.254393] (driver?) +[ 0.254514] 010c 4096 ram12 +[ 0.254516] (driver?) +[ 0.254639] 010d 4096 ram13 +[ 0.254640] (driver?) +[ 0.254755] 010e 4096 ram14 +[ 0.254756] (driver?) +[ 0.254871] 010f 4096 ram15 +[ 0.254872] (driver?) +[ 0.254996] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) +[ 0.255115] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.31 #1 +[ 0.255215] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.255339] Call Trace: +[ 0.255387] <TASK> +[ 0.255430] dump_stack_lvl+0x34/0x44 +[ 0.255499] panic+0xe8/0x27a +[ 0.255563] mount_block_root+0x16b/0x1fe +[ 0.255631] ? rest_init+0xc0/0xc0 +[ 0.255692] prepare_namespace+0x131/0x160 +[ 0.255757] ? rest_init+0xc0/0xc0 +[ 0.255823] kernel_init+0x11/0x100 +[ 0.255889] ret_from_fork+0x22/0x30 +[ 0.255969] </TASK> +[ 0.256061] Kernel Offset: disabled +[ 0.256130] Rebooting in 1 seconds.. +``` +Steps to reproduce: +1. build kernel with right config (build_kernel from kata-containers) with sev support (-x sev) & get kata-containers initrd +2. Launch the command on a AMD SEV compatible device + +This is a complex problem I guess I can provide more informations if needed. +Additional information: +We didn't see any logs from QEMU when running this command line even when putting -D file... + +Complete output from QEMU 6.2.0 with SEV : +``` +[ 0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021 +[ 0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.70 by EDK II +[ 0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118 +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 3d401001, primary cpu clock +[ 0.000000] kvm-clock: using sched offset of 4061892066 cycles +[ 0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000006] tsc: Detected 2994.372 MHz processor +[ 0.000159] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000162] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000169] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000 +[ 0.000215] MTRR default type: write-back +[ 0.000216] MTRR fixed ranges enabled: +[ 0.000218] 00000-9FFFF write-back +[ 0.000219] A0000-FFFFF uncachable +[ 0.000220] MTRR variable ranges enabled: +[ 0.000222] 0 base 0000C0000000 mask FFFFC0000000 uncachable +[ 0.000224] 1 base 0000B0000000 mask FFFFF0000000 uncachable +[ 0.000225] 2 base 001000000000 mask FFF800000000 uncachable +[ 0.000226] 3 disabled +[ 0.000227] 4 disabled +[ 0.000228] 5 disabled +[ 0.000229] 6 disabled +[ 0.000229] 7 disabled +[ 0.000277] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.008747] Using GB pages for direct mapping +[ 0.009448] Secure boot could not be determined +[ 0.009466] ACPI: Early table checksum verification disabled +[ 0.009476] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS ) +[ 0.009482] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS BXPC 00000001 01000013) +[ 0.009490] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009497] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009502] ACPI: FACS 0x000000007F9DD000 000040 +[ 0.009506] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009510] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009515] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009519] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009523] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009532] ACPI: Local APIC address 0xfee00000 +[ 0.009575] Zone ranges: +[ 0.009576] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.009578] DMA32 [mem 0x0000000001000000-0x000000007fe5ffff] +[ 0.009580] Normal empty +[ 0.009581] Device empty +[ 0.009582] Movable zone start for each node +[ 0.009583] Early memory node ranges +[ 0.009585] node 0: [mem 0x0000000000001000-0x000000000009ffff] +[ 0.009587] node 0: [mem 0x0000000000100000-0x00000000007fffff] +[ 0.009588] node 0: [mem 0x0000000000808000-0x000000000080ffff] +[ 0.009589] node 0: [mem 0x0000000000900000-0x000000007f6eefff] +[ 0.009590] node 0: [mem 0x000000007f9ff000-0x000000007fe5ffff] +[ 0.009592] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff] +[ 0.009595] On node 0 totalpages: 522743 +[ 0.009596] DMA zone: 59 pages used for memmap +[ 0.009597] DMA zone: 1814 pages reserved +[ 0.009599] DMA zone: 3751 pages, LIFO batch:0 +[ 0.009931] DMA zone: 29017 pages in unavailable ranges +[ 0.009933] DMA32 zone: 8122 pages used for memmap +[ 0.009934] DMA32 zone: 518992 pages, LIFO batch:63 +[ 0.014254] DMA32 zone: 1200 pages in unavailable ranges +[ 0.014984] ACPI: PM-Timer IO Port: 0x608 +[ 0.014988] ACPI: Local APIC address 0xfee00000 +[ 0.015002] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.015201] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +[ 0.015205] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.015207] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.015209] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.015210] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.015212] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.015213] ACPI: IRQ0 used by override. +[ 0.015214] ACPI: IRQ5 used by override. +[ 0.015216] ACPI: IRQ9 used by override. +[ 0.015217] ACPI: IRQ10 used by override. +[ 0.015217] ACPI: IRQ11 used by override. +[ 0.015220] Using ACPI (MADT) for SMP configuration information +[ 0.015223] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.015228] TSC deadline timer available +[ 0.015233] smpboot: Allowing 32 CPUs, 31 hotplug CPUs +[ 0.015245] kvm-guest: KVM setup pv remote TLB flush +[ 0.015254] kvm-guest: setup PV sched yield +[ 0.015272] [mem 0xc0000000-0xffffffff] available for PCI devices +[ 0.015274] Booting paravirtualized kernel on KVM +[ 0.015278] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns +[ 0.020479] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1 +[ 0.021723] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144 +[ 0.021732] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152 +[ 0.021734] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 +[ 0.021744] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31 +[ 0.027310] kvm-guest: KVM setup async PF for cpu 0 +[ 0.027318] kvm-guest: stealtime: cpu 0, msr 7d622080 +[ 0.027332] Built 1 zonelists, mobility grouping on. Total pages: 512748 +[ 0.027335] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.027480] printk: log_buf_len individual max cpu contribution: 4096 bytes +[ 0.027481] printk: log_buf_len total cpu_extra contributions: 126976 bytes +[ 0.027483] printk: log_buf_len min size: 131072 bytes +[ 0.027731] printk: log_buf_len: 262144 bytes +[ 0.027733] printk: early log buf free: 123344(94%) +[ 0.027942] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.028047] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.028190] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.041061] Memory: 1815804K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 274912K reserved, 0K cma-reserved) +[ 0.041173] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 +[ 0.041309] rcu: Hierarchical RCU implementation. +[ 0.041311] rcu: RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32. +[ 0.041312] All grace periods are expedited (rcu_expedited). +[ 0.041313] Tracing variant of Tasks RCU enabled. +[ 0.041315] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.041316] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32 +[ 0.041372] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16 +[ 0.041910] rcu: Offload RCU callbacks from CPUs: (none). +[ 0.042080] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0 +[ 0.042159] Console: colour dummy device 80x25 +[ 0.162231] printk: console [ttyS0] enabled +[ 0.175286] AMD Memory Encryption Features active: SEV +[ 0.176044] ACPI: Core revision 20200925 +[ 0.176768] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.178070] APIC: Switch to symmetric I/O mode setup +[ 0.180011] x2apic enabled +[ 0.182376] Switched APIC routing to physical x2apic. +[ 0.183044] kvm-guest: setup PV IPIs +[ 0.189694] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.190655] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.191992] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488) +[ 0.193096] pid_max: default: 32768 minimum: 301 +[ 0.224045] LSM: Security Framework initializing +[ 0.225340] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.226368] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.227912] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.228021] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.228758] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.229578] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.230655] Spectre V2 : Mitigation: Full AMD retpoline +[ 0.231993] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.233038] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.234868] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.235997] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.237657] Freeing SMP alternatives memory: 28K +[ 0.238528] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.239991] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.239991] ... version: 0 +[ 0.239991] ... bit width: 48 +[ 0.239991] ... generic registers: 6 +[ 0.239997] ... value mask: 0000ffffffffffff +[ 0.240552] ... max period: 00007fffffffffff +[ 0.241107] ... fixed-purpose events: 0 +[ 0.241610] ... event mask: 000000000000003f +[ 0.242405] rcu: Hierarchical SRCU implementation. +[ 0.243319] smp: Bringing up secondary CPUs ... +[ 0.243787] smp: Brought up 1 node, 1 CPU +[ 0.244000] smpboot: Max logical packages: 32 +[ 0.244475] smpboot: Total of 1 processors activated (5988.74 BogoMIPS) +[ 0.245487] devtmpfs: initialized +[ 0.245852] x86/mm: Memory block size: 128MB +[ 0.246502] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.247472] futex hash table entries: 8192 (order: 7, 524288 bytes, linear) +[ 0.248308] NET: Registered protocol family 16 +[ 0.249031] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations +[ 0.250111] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.251331] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.252043] thermal_sys: Registered thermal governor 'step_wise' +[ 0.252048] cpuidle: using governor menu +[ 0.253569] ACPI: bus type PCI registered +[ 0.253974] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.254656] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.255546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.256020] PCI: Using configuration type 1 for base access +[ 0.257219] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.257889] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.258633] ACPI: Added _OSI(Module Device) +[ 0.259073] ACPI: Added _OSI(Processor Device) +[ 0.259531] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.259999] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.260534] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.260979] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.261508] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.263748] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.264963] ACPI: Interpreter enabled +[ 0.265375] ACPI: (supports S0 S5) +[ 0.265743] ACPI: Using IOAPIC for interrupt routing +[ 0.266290] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.267390] ACPI: Enabled 3 GPEs in block 00 to 3F +[ 0.272364] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.273025] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.274136] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR] +[ 0.275108] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability] +[ 0.276009] PCI host bridge to bus 0000:00 +[ 0.276413] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.277047] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.277707] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.278440] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.279154] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.279885] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window] +[ 0.279995] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.280579] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.281678] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000 +[ 0.283998] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff] +[ 0.287128] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref] +[ 0.288918] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400 +[ 0.294626] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000 +[ 0.296349] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff] +[ 0.299044] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref] +[ 0.300892] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00 +[ 0.303526] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref] +[ 0.304902] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200 +[ 0.306875] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff] +[ 0.309436] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref] +[ 0.311525] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.312373] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.314653] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.318160] pci 0000:00:1f.2: reg 0x20: [io 0x6040-0x605f] +[ 0.319336] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff] +[ 0.320607] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.323429] pci 0000:00:1f.3: reg 0x20: [io 0x6000-0x603f] +[ 0.325167] pci_bus 0000:01: extended config space not accessible +[ 0.325943] acpiphp: Slot [0] registered +[ 0.326344] acpiphp: Slot [1] registered +[ 0.326753] acpiphp: Slot [2] registered +[ 0.327153] acpiphp: Slot [3] registered +[ 0.327557] acpiphp: Slot [4] registered +[ 0.327962] acpiphp: Slot [5] registered +[ 0.328009] acpiphp: Slot [6] registered +[ 0.328416] acpiphp: Slot [7] registered +[ 0.328817] acpiphp: Slot [8] registered +[ 0.329218] acpiphp: Slot [9] registered +[ 0.329625] acpiphp: Slot [10] registered +[ 0.330033] acpiphp: Slot [11] registered +[ 0.330448] acpiphp: Slot [12] registered +[ 0.330854] acpiphp: Slot [13] registered +[ 0.331261] acpiphp: Slot [14] registered +[ 0.331675] acpiphp: Slot [15] registered +[ 0.332008] acpiphp: Slot [16] registered +[ 0.332419] acpiphp: Slot [17] registered +[ 0.332827] acpiphp: Slot [18] registered +[ 0.333234] acpiphp: Slot [19] registered +[ 0.333647] acpiphp: Slot [20] registered +[ 0.334055] acpiphp: Slot [21] registered +[ 0.334468] acpiphp: Slot [22] registered +[ 0.334886] acpiphp: Slot [23] registered +[ 0.335298] acpiphp: Slot [24] registered +[ 0.335702] acpiphp: Slot [25] registered +[ 0.336008] acpiphp: Slot [26] registered +[ 0.336420] acpiphp: Slot [27] registered +[ 0.336824] acpiphp: Slot [28] registered +[ 0.337232] acpiphp: Slot [29] registered +[ 0.337636] acpiphp: Slot [30] registered +[ 0.338041] acpiphp: Slot [31] registered +[ 0.338650] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.339776] pci_bus 0000:00: on NUMA node 0 +[ 0.340242] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.340849] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.341462] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.342076] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.342685] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) +[ 0.343300] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) +[ 0.343918] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) +[ 0.344059] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) +[ 0.344636] ACPI: PCI Interrupt Link [GSIA] (IRQs *16) +[ 0.345142] ACPI: PCI Interrupt Link [GSIB] (IRQs *17) +[ 0.345660] ACPI: PCI Interrupt Link [GSIC] (IRQs *18) +[ 0.346245] ACPI: PCI Interrupt Link [GSID] (IRQs *19) +[ 0.346799] ACPI: PCI Interrupt Link [GSIE] (IRQs *20) +[ 0.347365] ACPI: PCI Interrupt Link [GSIF] (IRQs *21) +[ 0.347889] ACPI: PCI Interrupt Link [GSIG] (IRQs *22) +[ 0.348004] ACPI: PCI Interrupt Link [GSIH] (IRQs *23) +[ 0.349647] iommu: Default domain type: Translated +[ 0.350207] vgaarb: loaded +[ 0.350578] SCSI subsystem initialized +[ 0.350959] pps_core: LinuxPPS API ver. 1 registered +[ 0.351500] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.352007] PTP clock support registered +[ 0.352415] Registered efivars operations +[ 0.352914] PCI: Using ACPI for IRQ routing +[ 0.353321] PCI: pci_cache_line_size set to 64 bytes +[ 0.353916] e820: reserve RAM buffer [mem 0x00810000-0x008fffff] +[ 0.354487] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff] +[ 0.355053] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff] +[ 0.355719] clocksource: Switched to clocksource kvm-clock +[ 0.355991] pnp: PnP ACPI init +[ 0.355991] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.355991] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.355991] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.355991] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.355991] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.356347] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.357410] pnp: PnP ACPI: found 5 devices +[ 0.362961] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.363871] NET: Registered protocol family 2 +[ 0.364474] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear) +[ 0.365307] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 0.366095] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear) +[ 0.366893] TCP: Hash tables configured (established 16384 bind 16384) +[ 0.367563] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.368255] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.369036] NET: Registered protocol family 1 +[ 0.369533] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.371860] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.372477] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.373092] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.373765] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.374428] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.375109] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window] +[ 0.375904] PCI: CLS 0 bytes, default 64 +[ 0.376370] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 0.377008] software IO TLB: mapped [mem 0x000000006f600000-0x0000000073600000] (64MB) +[ 0.377807] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.379980] workingset: timestamp_bits=46 max_order=19 bucket_order=0 +[ 0.381847] fuse: init (API version 7.32) +[ 0.382462] SGI XFS with security attributes, no debug enabled +[ 0.383337] 9p: Installing v9fs 9p2000 file system support +[ 0.383950] NET: Registered protocol family 38 +[ 0.384407] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 0.385291] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 0.386003] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 0.386731] ACPI: Power Button [PWRF] +[ 0.387428] PCI Interrupt Link [GSIF] enabled at IRQ 21 +[ 0.388885] PCI Interrupt Link [GSIH] enabled at IRQ 23 +[ 0.390255] PCI Interrupt Link [GSIE] enabled at IRQ 20 +[ 0.393749] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 0.394570] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 0.409740] software IO TLB: Memory encryption is active and system is using DMA bounce buffers +[ 0.411320] printk: console [hvc0] enabled +[ 0.413415] brd: module loaded +[ 0.414644] loop: module loaded +[ 0.416081] scsi host0: Virtio SCSI HBA +[ 0.417023] random: fast init done +[ 0.417469] VFIO - User Level meta-driver version: 0.3 +[ 0.418175] random: crng init done +[ 0.418975] xt_time: kernel timezone is -0000 +[ 0.419488] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) +[ 0.420221] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) +[ 0.421119] IPVS: ipvs loaded. +[ 0.421478] IPVS: [rr] scheduler registered. +[ 0.421979] IPVS: [wrr] scheduler registered. +[ 0.422475] IPVS: [lc] scheduler registered. +[ 0.422970] IPVS: [wlc] scheduler registered. +[ 0.423461] IPVS: [fo] scheduler registered. +[ 0.423982] IPVS: [ovf] scheduler registered. +[ 0.424546] IPVS: [lblc] scheduler registered. +[ 0.425067] IPVS: [lblcr] scheduler registered. +[ 0.425580] IPVS: [dh] scheduler registered. +[ 0.426081] IPVS: [sh] scheduler registered. +[ 0.426572] IPVS: [sed] scheduler registered. +[ 0.427084] IPVS: [nq] scheduler registered. +[ 0.427578] IPVS: ftp: loaded support on port[0] = 21 +[ 0.428167] IPVS: [sip] pe registered. +[ 0.428794] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully +[ 0.429549] Initializing XFRM netlink socket +[ 0.430136] NET: Registered protocol family 10 +[ 0.430960] Segment Routing with IPv6 +[ 0.431417] NET: Registered protocol family 17 +[ 0.431971] 9pnet: Installing 9P2000 support +[ 0.433142] NET: Registered protocol family 40 +[ 0.433718] IPI shorthand broadcast: enabled +[ 0.434218] sched_clock: Marking stable (290414430, 142054672)->(447457221, -14988119) +[ 0.435600] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 +[ 0.436567] Please append a correct "root=" boot option; here are the available partitions: +[ 0.437750] 0100 4096 ram0 +[ 0.437750] (driver?) +[ 0.438478] 0101 4096 ram1 +[ 0.438478] (driver?) +[ 0.439182] 0102 4096 ram2 +[ 0.439183] (driver?) +[ 0.439896] 0103 4096 ram3 +[ 0.439897] (driver?) +[ 0.440629] 0104 4096 ram4 +[ 0.440630] (driver?) +[ 0.441346] 0105 4096 ram5 +[ 0.441346] (driver?) +[ 0.442052] 0106 4096 ram6 +[ 0.442053] (driver?) +[ 0.442756] 0107 4096 ram7 +[ 0.442756] (driver?) +[ 0.443457] 0108 4096 ram8 +[ 0.443457] (driver?) +[ 0.444177] 0109 4096 ram9 +[ 0.444177] (driver?) +[ 0.444893] 010a 4096 ram10 +[ 0.444893] (driver?) +[ 0.445609] 010b 4096 ram11 +[ 0.445610] (driver?) +[ 0.446339] 010c 4096 ram12 +[ 0.446340] (driver?) +[ 0.447056] 010d 4096 ram13 +[ 0.447057] (driver?) +[ 0.447781] 010e 4096 ram14 +[ 0.447781] (driver?) +[ 0.448512] 010f 4096 ram15 +[ 0.448513] (driver?) +[ 0.449263] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) +[ 0.450170] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.25 #1 +[ 0.450848] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.451699] Call Trace: +[ 0.451995] dump_stack+0x57/0x6a +[ 0.452378] panic+0xf6/0x292 +[ 0.452745] mount_block_root+0x2aa/0x324 +[ 0.453197] ? rest_init+0xaa/0xaa +[ 0.453587] prepare_namespace+0x131/0x160 +[ 0.454053] ? rest_init+0xaa/0xaa +[ 0.454442] kernel_init+0x5/0xf6 +[ 0.454838] ret_from_fork+0x22/0x30 +[ 0.455282] Kernel Offset: disabled +[ 0.455676] Rebooting in 1 seconds.. +``` + +Complete output from QEMU 6.2.0 without SEV : +``` +[ 0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021 +[ 0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.70 by EDK II +[ 0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e687118 +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 37201001, primary cpu clock +[ 0.000000] kvm-clock: using sched offset of 2589542167 cycles +[ 0.000002] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000004] tsc: Detected 2994.372 MHz processor +[ 0.000078] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000081] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000084] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000 +[ 0.000106] MTRR default type: write-back +[ 0.000107] MTRR fixed ranges enabled: +[ 0.000108] 00000-9FFFF write-back +[ 0.000109] A0000-FFFFF uncachable +[ 0.000110] MTRR variable ranges enabled: +[ 0.000111] 0 base 0000C0000000 mask FFFFC0000000 uncachable +[ 0.000111] 1 base 0000B0000000 mask FFFFF0000000 uncachable +[ 0.000112] 2 base 001000000000 mask FFF800000000 uncachable +[ 0.000113] 3 disabled +[ 0.000113] 4 disabled +[ 0.000114] 5 disabled +[ 0.000114] 6 disabled +[ 0.000114] 7 disabled +[ 0.000141] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.004269] Using GB pages for direct mapping +[ 0.004654] Secure boot could not be determined +[ 0.004655] RAMDISK: [mem 0x6f1ee000-0x757f5fff] +[ 0.004668] ACPI: Early table checksum verification disabled +[ 0.004673] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS ) +[ 0.004676] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS BXPC 00000001 01000013) +[ 0.004682] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004686] ACPI: DSDT 0x000000007F979000 003EAE (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004688] ACPI: FACS 0x000000007F9DD000 000040 +[ 0.004690] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004692] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004694] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004696] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004698] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.004703] ACPI: Local APIC address 0xfee00000 +[ 0.004734] Zone ranges: +[ 0.004735] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.004736] DMA32 [mem 0x0000000001000000-0x000000007fe5ffff] +[ 0.004737] Normal empty +[ 0.004738] Device empty +[ 0.004739] Movable zone start for each node +[ 0.004740] Early memory node ranges +[ 0.004741] node 0: [mem 0x0000000000001000-0x000000000009ffff] +[ 0.004742] node 0: [mem 0x0000000000100000-0x00000000007fffff] +[ 0.004743] node 0: [mem 0x0000000000808000-0x000000000080ffff] +[ 0.004743] node 0: [mem 0x0000000000900000-0x000000007f6eefff] +[ 0.004744] node 0: [mem 0x000000007f9ff000-0x000000007fe5ffff] +[ 0.004746] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff] +[ 0.004747] On node 0 totalpages: 522743 +[ 0.004748] DMA zone: 59 pages used for memmap +[ 0.004749] DMA zone: 1814 pages reserved +[ 0.004750] DMA zone: 3751 pages, LIFO batch:0 +[ 0.005315] DMA zone: 29017 pages in unavailable ranges +[ 0.005316] DMA32 zone: 8122 pages used for memmap +[ 0.005317] DMA32 zone: 518992 pages, LIFO batch:63 +[ 0.011640] DMA32 zone: 1200 pages in unavailable ranges +[ 0.012025] ACPI: PM-Timer IO Port: 0x608 +[ 0.012028] ACPI: Local APIC address 0xfee00000 +[ 0.012037] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.012063] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.012065] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.012067] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.012068] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.012069] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.012070] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.012071] ACPI: IRQ0 used by override. +[ 0.012072] ACPI: IRQ5 used by override. +[ 0.012073] ACPI: IRQ9 used by override. +[ 0.012073] ACPI: IRQ10 used by override. +[ 0.012074] ACPI: IRQ11 used by override. +[ 0.012076] Using ACPI (MADT) for SMP configuration information +[ 0.012077] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.012082] TSC deadline timer available +[ 0.012085] smpboot: Allowing 32 CPUs, 31 hotplug CPUs +[ 0.012093] kvm-guest: KVM setup pv remote TLB flush +[ 0.012099] kvm-guest: setup PV sched yield +[ 0.012110] [mem 0xc0000000-0xffffffff] available for PCI devices +[ 0.012116] Booting paravirtualized kernel on KVM +[ 0.012119] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns +[ 0.015048] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1 +[ 0.016599] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144 +[ 0.016605] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152 +[ 0.016606] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 +[ 0.016611] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31 +[ 0.016637] kvm-guest: KVM setup async PF for cpu 0 +[ 0.016641] kvm-guest: stealtime: cpu 0, msr 6e822080 +[ 0.016645] Built 1 zonelists, mobility grouping on. Total pages: 512748 +[ 0.016646] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.016721] printk: log_buf_len individual max cpu contribution: 4096 bytes +[ 0.016722] printk: log_buf_len total cpu_extra contributions: 126976 bytes +[ 0.016723] printk: log_buf_len min size: 131072 bytes +[ 0.016904] printk: log_buf_len: 262144 bytes +[ 0.016905] printk: early log buf free: 123296(94%) +[ 0.017240] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.017535] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.017618] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.021841] Memory: 1782444K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 308272K reserved, 0K cma-reserved) +[ 0.021920] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 +[ 0.022033] rcu: Hierarchical RCU implementation. +[ 0.022034] rcu: RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32. +[ 0.022035] All grace periods are expedited (rcu_expedited). +[ 0.022036] Tracing variant of Tasks RCU enabled. +[ 0.022037] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.022038] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32 +[ 0.022058] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16 +[ 0.022381] rcu: Offload RCU callbacks from CPUs: (none). +[ 0.022525] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0 +[ 0.022585] Console: colour dummy device 80x25 +[ 0.103996] printk: console [ttyS0] enabled +[ 0.104387] ACPI: Core revision 20200925 +[ 0.104866] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.105761] APIC: Switch to symmetric I/O mode setup +[ 0.106341] x2apic enabled +[ 0.106708] Switched APIC routing to physical x2apic. +[ 0.107178] kvm-guest: setup PV IPIs +[ 0.108191] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.108739] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.109650] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488) +[ 0.113651] pid_max: default: 32768 minimum: 301 +[ 0.129407] LSM: Security Framework initializing +[ 0.129680] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.130330] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.131738] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.132339] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.132849] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.133655] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.134398] Spectre V2 : Mitigation: Full AMD retpoline +[ 0.134857] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.135570] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.136182] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.136913] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.137807] Freeing SMP alternatives memory: 28K +[ 0.138326] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.141129] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.141649] ... version: 0 +[ 0.141657] ... bit width: 48 +[ 0.142342] ... generic registers: 6 +[ 0.143012] ... value mask: 0000ffffffffffff +[ 0.143904] ... max period: 00007fffffffffff +[ 0.144790] ... fixed-purpose events: 0 +[ 0.145529] ... event mask: 000000000000003f +[ 0.145867] rcu: Hierarchical SRCU implementation. +[ 0.147346] smp: Bringing up secondary CPUs ... +[ 0.148411] smp: Brought up 1 node, 1 CPU +[ 0.149351] smpboot: Max logical packages: 32 +[ 0.149660] smpboot: Total of 1 processors activated (5988.74 BogoMIPS) +[ 0.151208] devtmpfs: initialized +[ 0.151830] x86/mm: Memory block size: 128MB +[ 0.152836] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.153662] futex hash table entries: 8192 (order: 7, 524288 bytes, linear) +[ 0.155199] NET: Registered protocol family 16 +[ 0.156041] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations +[ 0.157242] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.157661] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.159023] thermal_sys: Registered thermal governor 'step_wise' +[ 0.159027] cpuidle: using governor menu +[ 0.161335] ACPI: bus type PCI registered +[ 0.161655] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.162805] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.164441] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.165592] PCI: Using configuration type 1 for base access +[ 0.166553] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.167679] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.169123] ACPI: Added _OSI(Module Device) +[ 0.169657] ACPI: Added _OSI(Processor Device) +[ 0.170402] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.171180] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.172120] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.172866] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.173655] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.176672] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.178693] ACPI: Interpreter enabled +[ 0.179358] ACPI: (supports S0 S5) +[ 0.179937] ACPI: Using IOAPIC for interrupt routing +[ 0.180969] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.181842] ACPI: Enabled 3 GPEs in block 00 to 3F +[ 0.188692] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.189662] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.191262] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR] +[ 0.192546] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME PCIeCapability] +[ 0.193820] PCI host bridge to bus 0000:00 +[ 0.194509] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.195642] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.196770] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.197654] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.198902] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.200182] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window] +[ 0.201533] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.201712] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.203324] pci 0000:00:01.0: [1af4:1003] type 00 class 0x078000 +[ 0.205657] pci 0000:00:01.0: reg 0x10: [io 0x60c0-0x60ff] +[ 0.208353] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff] +[ 0.213657] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref] +[ 0.218281] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400 +[ 0.223034] pci 0000:00:03.0: [1af4:1004] type 00 class 0x010000 +[ 0.225394] pci 0000:00:03.0: reg 0x10: [io 0x6080-0x60bf] +[ 0.226822] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff] +[ 0.230911] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref] +[ 0.235919] pci 0000:00:04.0: [1af4:1005] type 00 class 0x00ff00 +[ 0.237656] pci 0000:00:04.0: reg 0x10: [io 0x6120-0x613f] +[ 0.241656] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref] +[ 0.244288] pci 0000:00:05.0: [1af4:1009] type 00 class 0x000200 +[ 0.247672] pci 0000:00:05.0: reg 0x10: [io 0x6040-0x607f] +[ 0.249624] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff] +[ 0.252855] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref] +[ 0.257540] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.258154] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.259985] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.264875] pci 0000:00:1f.2: reg 0x20: [io 0x6100-0x611f] +[ 0.267416] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff] +[ 0.269582] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.271746] pci 0000:00:1f.3: reg 0x20: [io 0x6000-0x603f] +[ 0.274063] pci_bus 0000:01: extended config space not accessible +[ 0.275352] acpiphp: Slot [0] registered +[ 0.276038] acpiphp: Slot [1] registered +[ 0.277675] acpiphp: Slot [2] registered +[ 0.278353] acpiphp: Slot [3] registered +[ 0.279150] acpiphp: Slot [4] registered +[ 0.279837] acpiphp: Slot [5] registered +[ 0.280509] acpiphp: Slot [6] registered +[ 0.281280] acpiphp: Slot [7] registered +[ 0.281677] acpiphp: Slot [8] registered +[ 0.282360] acpiphp: Slot [9] registered +[ 0.283032] acpiphp: Slot [10] registered +[ 0.283814] acpiphp: Slot [11] registered +[ 0.284510] acpiphp: Slot [12] registered +[ 0.285203] acpiphp: Slot [13] registered +[ 0.285678] acpiphp: Slot [14] registered +[ 0.286378] acpiphp: Slot [15] registered +[ 0.287111] acpiphp: Slot [16] registered +[ 0.288055] acpiphp: Slot [17] registered +[ 0.288803] acpiphp: Slot [18] registered +[ 0.289541] acpiphp: Slot [19] registered +[ 0.289674] acpiphp: Slot [20] registered +[ 0.290384] acpiphp: Slot [21] registered +[ 0.291086] acpiphp: Slot [22] registered +[ 0.291778] acpiphp: Slot [23] registered +[ 0.292480] acpiphp: Slot [24] registered +[ 0.293211] acpiphp: Slot [25] registered +[ 0.293674] acpiphp: Slot [26] registered +[ 0.294385] acpiphp: Slot [27] registered +[ 0.295071] acpiphp: Slot [28] registered +[ 0.295953] acpiphp: Slot [29] registered +[ 0.296769] acpiphp: Slot [30] registered +[ 0.297594] acpiphp: Slot [31] registered +[ 0.297916] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.300138] pci_bus 0000:00: on NUMA node 0 +[ 0.301275] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.301748] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.302965] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.304172] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.305263] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) +[ 0.305787] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) +[ 0.306849] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) +[ 0.308110] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) +[ 0.309202] ACPI: PCI Interrupt Link [GSIA] (IRQs *16) +[ 0.309667] ACPI: PCI Interrupt Link [GSIB] (IRQs *17) +[ 0.310565] ACPI: PCI Interrupt Link [GSIC] (IRQs *18) +[ 0.311446] ACPI: PCI Interrupt Link [GSID] (IRQs *19) +[ 0.312329] ACPI: PCI Interrupt Link [GSIE] (IRQs *20) +[ 0.313253] ACPI: PCI Interrupt Link [GSIF] (IRQs *21) +[ 0.313672] ACPI: PCI Interrupt Link [GSIG] (IRQs *22) +[ 0.314722] ACPI: PCI Interrupt Link [GSIH] (IRQs *23) +[ 0.317172] iommu: Default domain type: Translated +[ 0.317728] vgaarb: loaded +[ 0.318310] SCSI subsystem initialized +[ 0.318954] pps_core: LinuxPPS API ver. 1 registered +[ 0.319804] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.321326] PTP clock support registered +[ 0.321687] Registered efivars operations +[ 0.322500] PCI: Using ACPI for IRQ routing +[ 0.323211] PCI: pci_cache_line_size set to 64 bytes +[ 0.324206] e820: reserve RAM buffer [mem 0x00810000-0x008fffff] +[ 0.325212] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff] +[ 0.325657] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff] +[ 0.326754] clocksource: Switched to clocksource kvm-clock +[ 0.327844] pnp: PnP ACPI init +[ 0.328425] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.329649] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.329809] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.331078] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.332465] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.333902] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.335579] pnp: PnP ACPI: found 5 devices +[ 0.341670] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.343568] NET: Registered protocol family 2 +[ 0.345189] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear) +[ 0.346697] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 0.348298] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear) +[ 0.349954] TCP: Hash tables configured (established 16384 bind 16384) +[ 0.351468] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.352774] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.354001] NET: Registered protocol family 1 +[ 0.354738] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.359275] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.360332] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.361390] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.362681] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.364042] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.365243] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window] +[ 0.366666] PCI: CLS 0 bytes, default 64 +[ 0.367453] Trying to unpack rootfs image as initramfs... +[ 2.474287] Freeing initrd memory: 104480K +[ 2.474789] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 2.476083] workingset: timestamp_bits=46 max_order=19 bucket_order=0 +[ 2.477757] fuse: init (API version 7.32) +[ 2.478215] SGI XFS with security attributes, no debug enabled +[ 2.478997] 9p: Installing v9fs 9p2000 file system support +[ 2.479591] NET: Registered protocol family 38 +[ 2.480035] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 2.480870] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.481582] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 2.482309] ACPI: Power Button [PWRF] +[ 2.482943] PCI Interrupt Link [GSIF] enabled at IRQ 21 +[ 2.484131] PCI Interrupt Link [GSIH] enabled at IRQ 23 +[ 2.485303] PCI Interrupt Link [GSIE] enabled at IRQ 20 +[ 2.486896] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 2.487599] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 2.513070] printk: console [hvc0] enabled +[ 2.514550] brd: module loaded +[ 2.515360] random: fast init done +[ 2.516052] loop: module loaded +[ 2.516563] random: crng init done +[ 2.517477] scsi host0: Virtio SCSI HBA +[ 2.518342] VFIO - User Level meta-driver version: 0.3 +[ 2.519286] xt_time: kernel timezone is -0000 +[ 2.519803] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) +[ 2.520504] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) +[ 2.521364] IPVS: ipvs loaded. +[ 2.521734] IPVS: [rr] scheduler registered. +[ 2.522232] IPVS: [wrr] scheduler registered. +[ 2.522732] IPVS: [lc] scheduler registered. +[ 2.523234] IPVS: [wlc] scheduler registered. +[ 2.523733] IPVS: [fo] scheduler registered. +[ 2.524237] IPVS: [ovf] scheduler registered. +[ 2.524741] IPVS: [lblc] scheduler registered. +[ 2.525253] IPVS: [lblcr] scheduler registered. +[ 2.525778] IPVS: [dh] scheduler registered. +[ 2.526281] IPVS: [sh] scheduler registered. +[ 2.526770] IPVS: [sed] scheduler registered. +[ 2.527273] IPVS: [nq] scheduler registered. +[ 2.527761] IPVS: ftp: loaded support on port[0] = 21 +[ 2.528335] IPVS: [sip] pe registered. +[ 2.528913] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully +[ 2.529668] Initializing XFRM netlink socket +[ 2.530243] NET: Registered protocol family 10 +[ 2.530990] Segment Routing with IPv6 +[ 2.531446] NET: Registered protocol family 17 +[ 2.531980] 9pnet: Installing 9P2000 support +[ 2.532904] NET: Registered protocol family 40 +[ 2.533452] IPI shorthand broadcast: enabled +[ 2.533957] sched_clock: Marking stable (2450694990, 83251786)->(2555552194, -21605418) +[ 2.535774] Freeing unused decrypted memory: 2036K +[ 2.536717] Freeing unused kernel image (initmem) memory: 892K +[ 2.537482] Write protecting the kernel read-only data: 14336k +[ 2.538869] Freeing unused kernel image (text/rodata gap) memory: 2044K +[ 2.539890] Freeing unused kernel image (rodata/data gap) memory: 592K +[ 2.540714] Run /init as init process +[ 2.541191] with arguments: +[ 2.541582] /init +[ 2.541885] with environment: +[ 2.542325] HOME=/ +[ 2.542640] TERM=linux +``` + +Expected output as previous versions +Complete output from QEMU 6.0.0 with SEV : +``` +[ 0.000000] Linux version 5.10.25 (gitlab-runner@runner-buildah0) (gcc (Debian 11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Tue Dec 7 11:43:22 CET 2021 +[ 0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007f6eefff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007f6ef000-0x000000007f96efff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007f96f000-0x000000007f97efff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007f97f000-0x000000007f9fefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007f9ff000-0x000000007fe5ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fe60000-0x000000007fe7ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fe80000-0x000000007fffffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.70 by EDK II +[ 0.000000] efi: SMBIOS=0x7f7ab000 ACPI=0x7f97e000 ACPI 2.0=0x7f97e014 MEMATTR=0x7e9d8118 +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 14201001, primary cpu clock +[ 0.000001] kvm-clock: using sched offset of 3987202924 cycles +[ 0.000004] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns +[ 0.000006] tsc: Detected 2994.372 MHz processor +[ 0.000158] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000161] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000168] last_pfn = 0x7fe60 max_arch_pfn = 0x400000000 +[ 0.000215] MTRR default type: write-back +[ 0.000216] MTRR fixed ranges enabled: +[ 0.000218] 00000-9FFFF write-back +[ 0.000220] A0000-FFFFF uncachable +[ 0.000220] MTRR variable ranges enabled: +[ 0.000222] 0 base 0000C0000000 mask FFFFC0000000 uncachable +[ 0.000224] 1 base 0000B0000000 mask FFFFF0000000 uncachable +[ 0.000226] 2 base 001000000000 mask FFF800000000 uncachable +[ 0.000227] 3 disabled +[ 0.000227] 4 disabled +[ 0.000228] 5 disabled +[ 0.000229] 6 disabled +[ 0.000230] 7 disabled +[ 0.000274] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.008664] Using GB pages for direct mapping +[ 0.009370] Secure boot could not be determined +[ 0.009372] RAMDISK: [mem 0x6f1ee000-0x757f5fff] +[ 0.009399] ACPI: Early table checksum verification disabled +[ 0.009410] ACPI: RSDP 0x000000007F97E014 000024 (v02 BOCHS ) +[ 0.009415] ACPI: XSDT 0x000000007F97D0E8 000054 (v01 BOCHS BXPC 00000001 01000013) +[ 0.009423] ACPI: FACP 0x000000007F978000 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009430] ACPI: DSDT 0x000000007F979000 003278 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009435] ACPI: FACS 0x000000007F9DD000 000040 +[ 0.009439] ACPI: APIC 0x000000007F977000 000170 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009443] ACPI: HPET 0x000000007F976000 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009448] ACPI: SRAT 0x000000007F975000 0002D0 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009452] ACPI: MCFG 0x000000007F974000 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009456] ACPI: WAET 0x000000007F973000 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.009466] ACPI: Local APIC address 0xfee00000 +[ 0.009507] Zone ranges: +[ 0.009508] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.009511] DMA32 [mem 0x0000000001000000-0x000000007fe5ffff] +[ 0.009513] Normal empty +[ 0.009514] Device empty +[ 0.009516] Movable zone start for each node +[ 0.009517] Early memory node ranges +[ 0.009518] node 0: [mem 0x0000000000001000-0x000000000009ffff] +[ 0.009520] node 0: [mem 0x0000000000100000-0x00000000007fffff] +[ 0.009521] node 0: [mem 0x0000000000808000-0x000000000080ffff] +[ 0.009522] node 0: [mem 0x0000000000900000-0x000000007f6eefff] +[ 0.009523] node 0: [mem 0x000000007f9ff000-0x000000007fe5ffff] +[ 0.009525] Initmem setup node 0 [mem 0x0000000000001000-0x000000007fe5ffff] +[ 0.009528] On node 0 totalpages: 522743 +[ 0.009529] DMA zone: 59 pages used for memmap +[ 0.009531] DMA zone: 1814 pages reserved +[ 0.009532] DMA zone: 3751 pages, LIFO batch:0 +[ 0.009843] DMA zone: 29017 pages in unavailable ranges +[ 0.009845] DMA32 zone: 8122 pages used for memmap +[ 0.009846] DMA32 zone: 518992 pages, LIFO batch:63 +[ 0.014033] DMA32 zone: 1200 pages in unavailable ranges +[ 0.014785] ACPI: PM-Timer IO Port: 0x608 +[ 0.014788] ACPI: Local APIC address 0xfee00000 +[ 0.014803] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.014994] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +[ 0.014998] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.015001] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.015003] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.015005] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.015006] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.015007] ACPI: IRQ0 used by override. +[ 0.015009] ACPI: IRQ5 used by override. +[ 0.015010] ACPI: IRQ9 used by override. +[ 0.015011] ACPI: IRQ10 used by override. +[ 0.015011] ACPI: IRQ11 used by override. +[ 0.015014] Using ACPI (MADT) for SMP configuration information +[ 0.015017] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.015021] TSC deadline timer available +[ 0.015027] smpboot: Allowing 32 CPUs, 31 hotplug CPUs +[ 0.015039] kvm-guest: KVM setup pv remote TLB flush +[ 0.015048] kvm-guest: setup PV sched yield +[ 0.015065] [mem 0xc0000000-0xffffffff] available for PCI devices +[ 0.015066] Booting paravirtualized kernel on KVM +[ 0.015070] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns +[ 0.020345] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:32 nr_node_ids:1 +[ 0.021575] percpu: Embedded 42 pages/cpu s143360 r0 d28672 u262144 +[ 0.021585] pcpu-alloc: s143360 r0 d28672 u262144 alloc=1*2097152 +[ 0.021587] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 +[ 0.021596] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 [0] 24 25 26 27 28 29 30 31 +[ 0.027137] kvm-guest: KVM setup async PF for cpu 0 +[ 0.027144] kvm-guest: stealtime: cpu 0, msr 7d622080 +[ 0.027159] Built 1 zonelists, mobility grouping on. Total pages: 512748 +[ 0.027161] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 console=ttyS0 cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug panic=1 nr_cpus=32 scsi_mod.scan=none agent.log=debug +[ 0.027288] printk: log_buf_len individual max cpu contribution: 4096 bytes +[ 0.027290] printk: log_buf_len total cpu_extra contributions: 126976 bytes +[ 0.027291] printk: log_buf_len min size: 131072 bytes +[ 0.027523] printk: log_buf_len: 262144 bytes +[ 0.027524] printk: early log buf free: 123296(94%) +[ 0.027737] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.027850] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.027991] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.040909] Memory: 1711324K/2090972K available (10242K kernel code, 956K rwdata, 1456K rodata, 892K init, 3564K bss, 379392K reserved, 0K cma-reserved) +[ 0.041029] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 +[ 0.041170] rcu: Hierarchical RCU implementation. +[ 0.041171] rcu: RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=32. +[ 0.041173] All grace periods are expedited (rcu_expedited). +[ 0.041174] Tracing variant of Tasks RCU enabled. +[ 0.041176] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.041177] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=32 +[ 0.041233] NR_IRQS: 15616, nr_irqs: 680, preallocated irqs: 16 +[ 0.041739] rcu: Offload RCU callbacks from CPUs: (none). +[ 0.041913] random: get_random_bytes called from start_kernel+0x2fc/0x4ae with crng_init=0 +[ 0.041995] Console: colour dummy device 80x25 +[ 0.140890] printk: console [ttyS0] enabled +[ 0.154171] AMD Memory Encryption Features active: SEV +[ 0.154858] ACPI: Core revision 20200925 +[ 0.155536] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.156743] APIC: Switch to symmetric I/O mode setup +[ 0.158619] x2apic enabled +[ 0.160959] Switched APIC routing to physical x2apic. +[ 0.161554] kvm-guest: setup PV IPIs +[ 0.168397] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.169300] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 0.170521] Calibrating delay loop (skipped) preset value.. 5988.74 BogoMIPS (lpj=11977488) +[ 0.171487] pid_max: default: 32768 minimum: 301 +[ 0.202181] LSM: Security Framework initializing +[ 0.202548] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.203685] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) +[ 0.205011] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.205802] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.206525] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.207435] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.208419] Spectre V2 : Mitigation: Full AMD retpoline +[ 0.209026] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.209975] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.210523] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.211737] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.213043] Freeing SMP alternatives memory: 28K +[ 0.213721] smpboot: CPU0: AMD EPYC 7302P 16-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.214519] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.214519] ... version: 0 +[ 0.214519] ... bit width: 48 +[ 0.214519] ... generic registers: 6 +[ 0.214519] ... value mask: 0000ffffffffffff +[ 0.214525] ... max period: 00007fffffffffff +[ 0.215142] ... fixed-purpose events: 0 +[ 0.215616] ... event mask: 000000000000003f +[ 0.216346] rcu: Hierarchical SRCU implementation. +[ 0.217174] smp: Bringing up secondary CPUs ... +[ 0.217714] smp: Brought up 1 node, 1 CPU +[ 0.218184] smpboot: Max logical packages: 32 +[ 0.218527] smpboot: Total of 1 processors activated (5988.74 BogoMIPS) +[ 0.219686] devtmpfs: initialized +[ 0.220119] x86/mm: Memory block size: 128MB +[ 0.220864] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.221995] futex hash table entries: 8192 (order: 7, 524288 bytes, linear) +[ 0.222863] NET: Registered protocol family 16 +[ 0.223660] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations +[ 0.224813] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.225857] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.226565] thermal_sys: Registered thermal governor 'step_wise' +[ 0.226569] cpuidle: using governor menu +[ 0.228447] ACPI: bus type PCI registered +[ 0.228925] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.229775] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.230527] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.231331] PCI: Using configuration type 1 for base access +[ 0.232839] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages +[ 0.233641] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.234545] ACPI: Added _OSI(Module Device) +[ 0.235040] ACPI: Added _OSI(Processor Device) +[ 0.235568] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.236115] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.236745] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.237264] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.237886] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.240277] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.242125] ACPI: Interpreter enabled +[ 0.242530] ACPI: (supports S0 S5) +[ 0.242933] ACPI: Using IOAPIC for interrupt routing +[ 0.243537] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.244744] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 0.250149] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.250531] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.251661] acpi PNP0A08:00: _OSC: platform does not support [LTR] +[ 0.252454] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME PCIeCapability] +[ 0.253626] PCI host bridge to bus 0000:00 +[ 0.254115] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.254526] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.255309] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.256179] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.257045] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.257910] pci_bus 0000:00: root bus resource [mem 0x1000000000-0x17ffffffff window] +[ 0.258525] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.259223] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.260509] pci 0000:00:01.0: [1af4:1043] type 00 class 0x078000 +[ 0.263098] pci 0000:00:01.0: reg 0x14: [mem 0xc0003000-0xc0003fff] +[ 0.267149] pci 0000:00:01.0: reg 0x20: [mem 0x1000000000-0x1000003fff 64bit pref] +[ 0.269843] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400 +[ 0.275338] pci 0000:00:03.0: [1af4:1048] type 00 class 0x010000 +[ 0.277811] pci 0000:00:03.0: reg 0x14: [mem 0xc0002000-0xc0002fff] +[ 0.281320] pci 0000:00:03.0: reg 0x20: [mem 0x1000004000-0x1000007fff 64bit pref] +[ 0.284951] pci 0000:00:04.0: [1af4:1044] type 00 class 0x00ff00 +[ 0.287749] pci 0000:00:04.0: reg 0x20: [mem 0x1000008000-0x100000bfff 64bit pref] +[ 0.289851] pci 0000:00:05.0: [1af4:1049] type 00 class 0x000200 +[ 0.292301] pci 0000:00:05.0: reg 0x14: [mem 0xc0001000-0xc0001fff] +[ 0.295709] pci 0000:00:05.0: reg 0x20: [mem 0x100000c000-0x100000ffff 64bit pref] +[ 0.298275] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.299038] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.300211] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.306084] pci 0000:00:1f.2: reg 0x20: [io 0x6040-0x605f] +[ 0.307285] pci 0000:00:1f.2: reg 0x24: [mem 0xc0000000-0xc0000fff] +[ 0.309200] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.312072] pci 0000:00:1f.3: reg 0x20: [io 0x6000-0x603f] +[ 0.314207] pci_bus 0000:01: extended config space not accessible +[ 0.314817] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.317358] pci_bus 0000:00: on NUMA node 0 +[ 0.318107] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) +[ 0.318611] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) +[ 0.319355] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 0.320094] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 0.320826] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) +[ 0.321565] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) +[ 0.322302] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) +[ 0.322608] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) +[ 0.323292] ACPI: PCI Interrupt Link [GSIA] (IRQs *16) +[ 0.323908] ACPI: PCI Interrupt Link [GSIB] (IRQs *17) +[ 0.324522] ACPI: PCI Interrupt Link [GSIC] (IRQs *18) +[ 0.325132] ACPI: PCI Interrupt Link [GSID] (IRQs *19) +[ 0.325746] ACPI: PCI Interrupt Link [GSIE] (IRQs *20) +[ 0.326356] ACPI: PCI Interrupt Link [GSIF] (IRQs *21) +[ 0.326533] ACPI: PCI Interrupt Link [GSIG] (IRQs *22) +[ 0.327148] ACPI: PCI Interrupt Link [GSIH] (IRQs *23) +[ 0.329169] iommu: Default domain type: Translated +[ 0.329808] vgaarb: loaded +[ 0.330245] SCSI subsystem initialized +[ 0.330537] pps_core: LinuxPPS API ver. 1 registered +[ 0.331124] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.332182] PTP clock support registered +[ 0.332667] Registered efivars operations +[ 0.333281] PCI: Using ACPI for IRQ routing +[ 0.333783] PCI: pci_cache_line_size set to 64 bytes +[ 0.334528] e820: reserve RAM buffer [mem 0x00810000-0x008fffff] +[ 0.335230] e820: reserve RAM buffer [mem 0x7f6ef000-0x7fffffff] +[ 0.335932] e820: reserve RAM buffer [mem 0x7fe60000-0x7fffffff] +[ 0.336675] clocksource: Switched to clocksource kvm-clock +[ 0.337485] pnp: PnP ACPI init +[ 0.337896] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active) +[ 0.338519] pnp 00:01: Plug and Play ACPI device, IDs PNP0f13 (active) +[ 0.338519] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) +[ 0.338519] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.338920] system 00:04: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.339770] system 00:04: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.341103] pnp: PnP ACPI: found 5 devices +[ 0.346943] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.348014] NET: Registered protocol family 2 +[ 0.348722] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear) +[ 0.349720] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 0.350698] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear) +[ 0.351620] TCP: Hash tables configured (established 16384 bind 16384) +[ 0.352423] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.353213] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear) +[ 0.354115] NET: Registered protocol family 1 +[ 0.354654] pci 0000:00:02.0: PCI bridge to [bus 01] +[ 0.357279] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.358008] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.358744] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.359541] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.360345] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.361145] pci_bus 0000:00: resource 9 [mem 0x1000000000-0x17ffffffff window] +[ 0.362089] PCI: CLS 0 bytes, default 64 +[ 0.362638] Trying to unpack rootfs image as initramfs... +[ 2.307254] Freeing initrd memory: 104480K +[ 2.307791] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 2.308521] software IO TLB: mapped [mem 0x0000000069000000-0x000000006d000000] (64MB) +[ 2.309454] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b29812ce43, max_idle_ns: 440795323173 ns +[ 2.311063] workingset: timestamp_bits=46 max_order=19 bucket_order=0 +[ 2.313608] fuse: init (API version 7.32) +[ 2.314181] SGI XFS with security attributes, no debug enabled +[ 2.315435] 9p: Installing v9fs 9p2000 file system support +[ 2.316233] NET: Registered protocol family 38 +[ 2.316827] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 2.317926] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.318847] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 2.319752] ACPI: Power Button [PWRF] +[ 2.320661] PCI Interrupt Link [GSIF] enabled at IRQ 21 +[ 2.322549] PCI Interrupt Link [GSIH] enabled at IRQ 23 +[ 2.324157] PCI Interrupt Link [GSIE] enabled at IRQ 20 +[ 2.326555] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +[ 2.327388] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 2.341959] software IO TLB: Memory encryption is active and system is using DMA bounce buffers +[ 2.344242] printk: console [hvc0] enabled +[ 2.346335] brd: module loaded +[ 2.347023] random: fast init done +[ 2.347786] random: crng init done +[ 2.349418] loop: module loaded +[ 2.351182] scsi host0: Virtio SCSI HBA +[ 2.352317] VFIO - User Level meta-driver version: 0.3 +[ 2.353380] xt_time: kernel timezone is -0000 +[ 2.354028] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) +[ 2.354873] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) +[ 2.355859] IPVS: ipvs loaded. +[ 2.356319] IPVS: [rr] scheduler registered. +[ 2.356933] IPVS: [wrr] scheduler registered. +[ 2.357542] IPVS: [lc] scheduler registered. +[ 2.358152] IPVS: [wlc] scheduler registered. +[ 2.358787] IPVS: [fo] scheduler registered. +[ 2.359343] IPVS: [ovf] scheduler registered. +[ 2.359968] IPVS: [lblc] scheduler registered. +[ 2.360595] IPVS: [lblcr] scheduler registered. +[ 2.361236] IPVS: [dh] scheduler registered. +[ 2.361846] IPVS: [sh] scheduler registered. +[ 2.362468] IPVS: [sed] scheduler registered. +[ 2.363060] IPVS: [nq] scheduler registered. +[ 2.363623] IPVS: ftp: loaded support on port[0] = 21 +[ 2.364272] IPVS: [sip] pe registered. +[ 2.364967] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully +[ 2.365818] Initializing XFRM netlink socket +[ 2.366474] NET: Registered protocol family 10 +[ 2.367351] Segment Routing with IPv6 +[ 2.367888] NET: Registered protocol family 17 +[ 2.368518] 9pnet: Installing 9P2000 support +[ 2.369955] NET: Registered protocol family 40 +[ 2.370608] IPI shorthand broadcast: enabled +[ 2.371198] sched_clock: Marking stable (2249797515, 120751625)->(2381329269, -10780129) +[ 2.373554] Freeing unused decrypted memory: 2036K +[ 2.374622] Freeing unused kernel image (initmem) memory: 892K +[ 2.375403] Write protecting the kernel read-only data: 14336k +[ 2.377004] Freeing unused kernel image (text/rodata gap) memory: 2044K +[ 2.378219] Freeing unused kernel image (rodata/data gap) memory: 592K +[ 2.379114] Run /init as init process +[ 2.379599] with arguments: +[ 2.380009] /init +[ 2.380321] with environment: +[ 2.380749] HOME=/ +[ 2.381071] TERM=linux +``` diff --git a/results/classifier/105/KVM/957 b/results/classifier/105/KVM/957 new file mode 100644 index 00000000..30158572 --- /dev/null +++ b/results/classifier/105/KVM/957 @@ -0,0 +1,84 @@ +KVM: 0.905 +other: 0.850 +vnc: 0.830 +graphic: 0.819 +mistranslation: 0.752 +semantic: 0.741 +boot: 0.740 +instruction: 0.723 +socket: 0.712 +assembly: 0.709 +device: 0.705 +network: 0.690 + +qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code." +Description of problem: +The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is +``` +The futex facility returned an unexpected error code. +``` + +Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``. + +Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument". + + +``` +116876 get_thread_area(0x00000001) = 989882672 +116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672 + = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744 +futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000) + = 1065219744 +0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744 +116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument) + = 0 + = 116876 get_thread_area(0x3f7d4c34)1 = +116876 get_thread_area(0x00000000) = 1065219744 +926968112 +116876 get_thread_area(0x00000016) = 926968112 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000001)116876 = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112 +116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE +,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112 +1065219744 +116876 get_thread_area(0x00000001)116876 = 1065219744 +1073732112) = 116876 -1 errno=22 (Invalid argument) +futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112) +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0 +116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 + = 0 +116876 get_thread_area(0x40053a8c) = 885025072 +116876 get_thread_area(0x00000001) = 885025072 +116876 get_thread_area(0x00b4b456) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 Unknown syscall 403 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00003baa) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112 +116876 get_thread_area(0x00000018) = 926968112 +116876 get_thread_area(0x3ed5b9c8) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x0000000f) = 926968112116876 = 0 + +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112 +The futex facility returned an unexpected error code. +116876 get_thread_area(0x3f7d4c30) = 885025072 +``` + +Advice on how to do further debuggging is appreciated. diff --git a/results/classifier/105/KVM/961 b/results/classifier/105/KVM/961 new file mode 100644 index 00000000..44cff90c --- /dev/null +++ b/results/classifier/105/KVM/961 @@ -0,0 +1,14 @@ +KVM: 0.836 +instruction: 0.743 +other: 0.712 +network: 0.618 +semantic: 0.525 +device: 0.444 +mistranslation: 0.420 +graphic: 0.318 +boot: 0.145 +vnc: 0.066 +socket: 0.012 +assembly: 0.009 + +Property not found when using aarch64 `-machine=virt,secure=on` with KVM enabled diff --git a/results/classifier/105/KVM/964 b/results/classifier/105/KVM/964 new file mode 100644 index 00000000..3395ef0e --- /dev/null +++ b/results/classifier/105/KVM/964 @@ -0,0 +1,53 @@ +KVM: 0.389 +mistranslation: 0.378 +graphic: 0.346 +vnc: 0.342 +other: 0.324 +boot: 0.310 +semantic: 0.292 +device: 0.288 +network: 0.271 +instruction: 0.263 +assembly: 0.243 +socket: 0.242 + +arm64 defconfig kernel (4.14.275) no longer boots after FEAT_LPA implementation in TCG +Description of problem: +I am not really sure if this is a bug or merely a scenario where this is not expected to work. After 7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf, the attached `Image.gz` (`ARCH=arm64 defconfig`, based on the latest `linux-4.14.y`) just hangs with no output when using `-cpu max` (or `-cpu max,lpa2=off` due to 69b2265d5fe8e0f401d75e175e0a243a7d505e53). At 0af312b6edd231e1c8d0dec12494a80bc39ac761, `-cpu max` works just fine, as shown by the bisect log below. + +``` +$ git bisect log +# bad: [99eb313ddbbcf73c1adcdadceba1423b691c6d05] ui/cocoa: Use the standard about panel +# good: [44f28df24767cf9dca1ddc9b23157737c4cbb645] Update version for v6.2.0 release +git bisect start '99eb313ddbbcf73c1adcdadceba1423b691c6d05' 'v6.2.0' +# good: [2fc1b44dd0e7ea9ad5920352fd04179e4d6836d9] target/riscv: rvv-1.0: Allow Zve32f extension to be turned on +git bisect good 2fc1b44dd0e7ea9ad5920352fd04179e4d6836d9 +# good: [e64e27d5cb103b7764f1a05b6eda7e7fedd517c5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread +git bisect good e64e27d5cb103b7764f1a05b6eda7e7fedd517c5 +# good: [747ffe28cad7129e1d326d943228fdcbe109530d] pnv/xive2: Add support XIVE2 P9-compat mode (or Gen1) +git bisect good 747ffe28cad7129e1d326d943228fdcbe109530d +# bad: [4377683df969e715e3cb2dbd258e44f9ff51f788] edid: Fix clock of Detailed Timing Descriptor +git bisect bad 4377683df969e715e3cb2dbd258e44f9ff51f788 +# good: [755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d] migration: Move static var in ram_block_from_stream() into global +git bisect good 755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d +# bad: [6629bf78aac7e53f83fd0bcbdbe322e2302dfd1f] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20220302' into staging +git bisect bad 6629bf78aac7e53f83fd0bcbdbe322e2302dfd1f +# good: [0af312b6edd231e1c8d0dec12494a80bc39ac761] target/arm: Implement FEAT_LVA +git bisect good 0af312b6edd231e1c8d0dec12494a80bc39ac761 +# bad: [dc8bc9d6574aa563ed2fcc0ff495e77a2a2a8faa] target/arm: Report KVM's actual PSCI version to guest in dtb +git bisect bad dc8bc9d6574aa563ed2fcc0ff495e77a2a2a8faa +# bad: [d976de218c534735e307fc4a6c03e3ae764fd419] target/arm: Fix TLBIRange.base for 16k and 64k pages +git bisect bad d976de218c534735e307fc4a6c03e3ae764fd419 +# bad: [13e481c9335582fc7eed12e24e8d4d7068b24ff8] target/arm: Extend arm_fi_to_lfsc to level -1 +git bisect bad 13e481c9335582fc7eed12e24e8d4d7068b24ff8 +# bad: [7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf] target/arm: Implement FEAT_LPA +git bisect bad 7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf +# first bad commit: [7a928f43d8724bdf0777d7fc67a5ad973a0bf4bf] target/arm: Implement FEAT_LPA +``` + +A `4.19.237` kernel boots right up with `-cpu max`/`-cpu max,lpa2=off`. Is this expected behavior given the age of the kernel or is there something else going on here? If this is expected, should we be using something like `-cpu cortex-a72` for these older kernels? +Steps to reproduce: +Run the above command with the attached `Image.gz` and `rootfs.cpio`. +Additional information: +[Image.gz](/uploads/7b25b70f210354663b8e391290d3f39c/Image.gz) +[rootfs.cpio](/uploads/4793be1a500bdf615e212d3379c4c175/rootfs.cpio) diff --git a/results/classifier/105/KVM/965867 b/results/classifier/105/KVM/965867 new file mode 100644 index 00000000..f44d2d06 --- /dev/null +++ b/results/classifier/105/KVM/965867 @@ -0,0 +1,315 @@ +KVM: 0.930 +other: 0.895 +boot: 0.874 +instruction: 0.872 +graphic: 0.870 +device: 0.863 +assembly: 0.858 +vnc: 0.847 +semantic: 0.843 +socket: 0.840 +network: 0.836 +mistranslation: 0.787 + +9p virtual file system on qemu slow + +Hi, +The 9p virtual file system is slow. Several examples below: +--------------------------------------------------------- +Host for the first time: +$ time ls bam.unsorted/ +........................... +real 0m0.084s +user 0m0.000s +sys 0m0.028s +-------------------------------------------------- +Host second and following: + +real 0m0.009s +user 0m0.000s +sys 0m0.008s +------------------------------------------------------ +VM for the first time: +$ time ls bam.unsorted/ +................................ +real 0m23.141s +user 0m0.064s +sys 0m2.156s +------------------------------------------------------ +VM for the second time +real 0m3.643s +user 0m0.024s +sys 0m0.424s +---------------------------------------------------- + +Copy on host: +$ time cp 5173T.root.bak test.tmp +real 0m30.346s +user 0m0.004s +sys 0m5.324s + +$ ls -lahs test.tmp +2.7G -rw------- 1 oneadmin cloud 2.7G Mar 26 21:47 test.tmp + +--------------------------------------------------- +$ copy on VM for the same file + +time cp 5173T.root.bak test.tmp + +real 5m46.978s +user 0m0.352s +sys 1m38.962s + +Thanks for taking the time to report this bug. Which release are you currently using? Is this performance a regression over past releases? Would it be possible for you to test with upstream qemu to see whether performance has improved? + +Hi Serge, + +Here are info: + +max@s0:/var/lib/one/var$ uname -a +Linux s0 3.2.0-20-generic #33-Ubuntu SMP Tue Mar 27 16:42:26 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + + +max@s0:/var/lib/one/var$ kvm --version +QEMU emulator version 1.0 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard + + + ps aux| grep kvm | grep one-52 +oneadmin 62687 28.9 0.3 25283292 839204 ? Sl 01:31 2:22 /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 20040 -smp 60,sockets=60,cores=1,threads=1 -name one-52 -uuid 30c77a47-85c4-65dd-6c21-9d9b3e66cabe -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-52.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/var/lib/one/var//52/images/disk.0,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/one/var//52/images/disk.1,if=none,id=drive-virtio-disk4,format=raw,cache=writeback -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk4,id=virtio-disk4 -fsdev local,security_model=mapped,id=fsdev-fs0,path=/tank/biouml-shared -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=VirtFS,bus=pci.0,addr=0x3 -netdev tap,fd=21,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:1e,bus=pci.0,addr=0x4 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:52 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -cpu host + + +Thanks. + +I'm posting a new package based on today's git head of upstream at ppa:ubuntu-virt/ppa. When (and if) that builds, is it possible for you to try with that version? Then we will know whether to file this bug upstream, or find and cherrypick the fixes. + +Hi Serge, + +syslogs on host completely clean for all my 3 bugs. No messages at all regarding any errors. + +I just added this repository. I can basically update now daily as I have to reboot server daily to make kvm working. +I installed qemu version: 1.0+noroms-20120220-0ubuntu1. + + + +Quoting max (<email address hidden>): +> Hi Serge, +> +> syslogs on host completely clean for all my 3 bugs. No messages at all +> regarding any errors. + +Thanks. + +> I just added this repository. I can basically update now daily as I have to reboot server daily to make kvm working. +> I installed qemu version: 1.0+noroms-20120220-0ubuntu1. + +1.0+noroms-20120330-0ubuntu1 should now be available, though of course +if the issue is fixed in 1.0+noroms-20120220-0ubuntu1 then that's even +more helpful :) + + +Hi Serge, + +I tried new build. It is not working for me. I got this message: + +max@s0:/var/lib/one/var$ virsh create 52/deployment.0 +error: Failed to create domain from 52/deployment.0 +error: internal error process exited while connecting to monitor: kvm: -fsdev local,security_model=mapped,id=fsdev-fs0,path=/tank/biouml-shared: there is no option group "fsdev" +fsdev is not supported by this qemu build. + + +Drat. + +I'll simply need to try to reproduce. + +Hi Serge, + +qemu build 0330 does not support -fsdev. I was not able to start kvm with 9p at all. + +If you will make another build I will try it too. + +Thanks + +Quoting max (<email address hidden>): +> Hi Serge, +> +> qemu build 0330 does not support -fsdev. I was not able to start kvm +> with 9p at all. +> +> If you will make another build I will try it too. + +Thanks. Sorry about that. I'm hoping I just used an old packaging +tree as my starting base, will re-try, and post here when it has +built. + + +Hi, + +version 1.0+noroms-20120330-0ubuntu3 has been built. Could you verify whether that fixes the issue (as well as your others)? + +Thanks Serge, + +I installed it and now testing. Let's wait for several days. I will write if have any issues. + +Hi Serge, +Stability bugs was fixed in KVM, thanks! +Unfortunately this one still here: + +---------------------------------------------------------------------------- +VM: + + ls -las XXXXX.bam +14537970 -rw-r--r-- 1 10001 cloud 14885246140 Mar 23 12:19 XXXXX.bam + + +time cp XXXX.bam test.tmp + +real 14m45.580s +user 0m0.420s +sys 1m45.823s + +~16 Mb/sec +-------------------------------------------------------------- +Host: +$ ls -las 5173N_sorted_dedup_rg_dd2_kar.chr4.ra.dd.recal.bam +15220278 -rw-r--r-- 1 oneadmin cloud 15583853314 Mar 27 18:53 YYYY.bam + + +time cp YYYYY.bam test.tmp + +real 4m38.525s +user 0m0.048s +sys 1m11.124s + +~53MB/sec + +Thanks, Max. Marked as affecting upstream QEMU per the last comment. + +Can you try with security_model=passthrough? + +One of possible problems could be a block size. In this case I am using ZFS with raidZ 4+1 drives. Each drive has 4Kb block. So optimal block size is 16384 bytes. By optimizing block size it possible to improve performance 10 folds but 9p stably provides 10 folds worse performance than native writes. + +Some extra tests: +--------------------- +VM - mapped + +$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 20.7879 s, 2.5 MB/s + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 74.4378 s, 22.0 MB/s +------------------------------------------------------------ +Host: +$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 1.60118 s, 32.0 MB/s + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 4.89932 s, 334 MB/s + + +Iggy: I has issue with permission in passthrough mode. Can you give an idea how to setup permissions in this mode? + +>>>Can you try with security_model=passthrough? +It provides the same results, see below: + +$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 19.8581 s, 2.6 MB/s + + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 72.3009 s, 22.7 MB/s + + +Hi Max, + +Could you try passing msize=262144 for 9p mount point and post the results? + +Host: +[root@llm116 media]# ls -lhas file +1.1G -rw-r--r-- 1 root root 1.0G Apr 26 11:05 file + +[root@llm116 media]# dd if=/dev/zero of=file bs=1M count=1024 +1024+0 records in +1024+0 records out +1073741824 bytes (1.1 GB) copied, 0.700828 s, 1.5 GB/s + +[root@llm116 media]# time cp file file2 + +real 0m6.353s +user 0m0.007s +sys 0m1.520s + +VM: + +[root@qemu-img-64 pass]# time cp file 9p_file + +real 0m12.261s +user 0m0.154s +sys 0m2.582s + +[root@qemu-img-64 pass]# dd if=/dev/zero of=file.9 bs=1M count=1024 +1024+0 records in +1024+0 records out +1073741824 bytes (1.1 GB) copied, 2.07335 s, 518 MB/s + +[root@qemu-img-64 pass]# mount +[snip] +v_pass on /pass type 9p (rw,trans=virtio,version=9p2000.L,msize=262144) +[/snip] + +Hi Mohan, +this parameter provide significant improvement in big file access/write: +-------------------------------------------------------------------------------------------- +VirtFS on /srv/shared type 9p (rw,trans=virtio,version=9p2000.L,msize=262144) + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 36.3589 s, 45.1 MB/s + +l$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 25.6597 s, 2.0 MB/s + +$ dd if=/dev/zero of=test count=1024 bs=262144 +1024+0 records in +1024+0 records out +268435456 bytes (268 MB) copied, 3.41936 s, 78.5 MB/s + +Speed of copy for large file ~45MB/s (read and write from the same disk). +--------------------------------------------------------------------------------------------- +But Host: +time ls -lahs bam.unsorted/ +many files: +real 0m0.053s +user 0m0.004s +sys 0m0.036s + +VM: +real 0m4.449s +user 0m0.012s +sys 0m0.136s +-------------------------------------------------------- +So we have delays on the first file access. +Is it possible to resolve this issue? + + + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/966316 b/results/classifier/105/KVM/966316 new file mode 100644 index 00000000..2633245c --- /dev/null +++ b/results/classifier/105/KVM/966316 @@ -0,0 +1,37 @@ +KVM: 0.939 +graphic: 0.893 +semantic: 0.818 +mistranslation: 0.813 +instruction: 0.811 +device: 0.785 +other: 0.780 +network: 0.673 +socket: 0.591 +vnc: 0.499 +boot: 0.433 +assembly: 0.351 + +Can't load Android VBOX image or even linux test image as well + +Can't load Android X86 ICS 4.0 VBOX image. +It worked with previous version before adding /qemu/hw/pc_sysfw.c file ( tested with version 1.0 ). + +x86_64-softmmu# ./qemu-system-x86_64 ~/kvm-test-image/x86-linux-0.2.img +qemu: PC system firmware (pflash) must be a multiple of 0x1000 + +In QEMU website (http://wiki.qemu.org/Testing), there is a test image for linux +but, new version can't load the image as well because of upper error. +linux-0.2.img.bz2 (8 MB) Small Linux disk image containing a 2.6.20 Linux kernel, X11 and various utilities to test QEMU + +I'm getting this same error with qemu v1.1.1 on a RAW formatted disk image of windows XP that used to work. + +> qemu -m 1024 -hda xp.img -localtime -net user +qemu: PC system firmware (pflash) must be a multiple of 0x1000 + +I've no idea what this error could mean =) + +Triaging old bug tickets ... Can you still reproduce this problem with +the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/KVM/992067 b/results/classifier/105/KVM/992067 new file mode 100644 index 00000000..554d178f --- /dev/null +++ b/results/classifier/105/KVM/992067 @@ -0,0 +1,46 @@ +KVM: 0.938 +graphic: 0.916 +instruction: 0.894 +boot: 0.869 +other: 0.847 +vnc: 0.801 +device: 0.786 +assembly: 0.758 +mistranslation: 0.749 +semantic: 0.717 +socket: 0.606 +network: 0.579 + +Windows 2008R2 very slow cold boot when >4GB memory + +I've been having a consistent problem booting 2008R2 guests with 4096MB of RAM or greater. On the initial boot the KVM process starts out with a ~200MB memory allocation and will use 100% of all CPU allocated to it. The RES memory of the KVM process slowly rises by around 200mb every few minutes until it reaches it's memory allocation (several hours in some cases). Whilst this is happening the guest will usually blue screen with the message of - + +A clock interrupt was not received on a secondary processor within the allocated time interval + +If I let the KVM process continue to run it will eventually allocate the required memory the guest will run at full speed, usually restarting after the blue screen and booting into startup repair. From here you can restart it and it will boot perfectly. Once booted the guest has no performance issues at all. + +I've tried everything I could think of. Removing PAE, playing with huge pages, different kernels, different userspaces, different systems, different backing file systems, different processor feature set, with or without Virtio etc. My best theory is that the problem is caused by Windows 2008 zeroing out all the memory on boot and something is causing this to be held up or slowed to a crawl. The hosts always have memory free to boot the guest and are not using swap at all. + +Nothing so far has solved the issue. A few observations I've made about the issue are - +Large memory 2008R2 guests seem to boot fine (or with a small delay) when they are the first to boot on the host after a reboot +Sometimes dropping the disk cache (echo 1 > /proc/sys/vm/drop_caches) will cause them to boot faster + + +The hosts I've tried are - +All Nehalem based (5540, 5620 and 5660) +Host ram of 48GB, 96GB and 192GB +Storage on NFS, Gluster and local (ext4, xfs and zfs) +QED, QCOW and RAW formats +Scientific Linux 6.1 with the standard kernel 2.6.32, 2.6.38 and 3.3.1 +KVM userspaces 0.12, 0.14 and (currently) 0.15.1 + +This should be resolved by using Hyper-V relaxed timers which is in the latest development version of QEMU. You would need to add -cpu host,+hv_relaxed to the command line to verify this. + +Thanks for the quick reply, + +I pulled the latest version from Git and on first attempt it said the hv_relaxed feature was not present. I checked the source and the 'hv_relaxed' feature was not included in a 'feature_name' array so the flag was being discarded before it could be enabled. + +Once added in to the 'feature_name' array it was enabled but the VM crashes on boot with a blue screen and the error message "Phase0_exception" followed by a reboot. + +Triaging old bug tickets... QEMU 0.12/0.14/0.15 is pretty outdated nowadays. Can you still reproduce this behavior with the latest version of QEMU? If not, I think we should close this bug... + |